AliothStudio состоит из двух цепочек с разделённой ответственностью; понимание их границ — предпосылка правильного использования платформы:
| Цепочка | Ответственность | Драйвер | Результат |
|---|---|---|---|
| Цепочка выпуска модели | Структурная эволюция основания данных (таблицы/столбцы/наследование/кодировки измерений) | Центр моделей Meta (ручной канал) | Пакет выпуска Alioth/v* (DDL · seed · машиночитаемый контракт · отчёт верификации) |
| Цепочка построения приложения | Сборка бизнес-приложений на замороженном основании | Агент AppAgent + разработчик | Конфигурация приложения, бэкенд Service, фронтенд модулей, пакет развёртывания Deploy/{ns} |
| Зависимость | Назначение |
|---|---|
| PostgreSQL 14+ | Основание данных (модель v10.0 — структура наследования таблиц) |
| mise | Единая точка входа для задач и окружения (mise run <task>) |
| Rust toolchain / pnpm / bun | Сборка бэкенда, сборка фронтенда, инструментальная цепочка скриптов |
# Инициализация базы разработки (воспроизведение из снапшота выпуска; выполняет DROP и пересоздание целевой БД, только aliothstudio_dev)
bash scripts/db/reset-db.sh --dev
# Платформа Meta (управление моделями + AppAgent): бэкенд :4949, фронтенд :49494
mise run meta
# Окружение разработки пространства имён (Gateway + SSO), {ns} ∈ alioth | wz | avic | cosmic | se | mat
mise run dev:{ns}aliothstudio ← предпродакшн aliothstudio_pre → разработка aliothstudio_dev → тестирование aliothstudio_test. Окружение жёстко привязано к DATABASE_URL; запросы к схеме выполняются исключительно через cd Meta/backend && mise run schema-info -- <command> (БД — единственный источник истины; выводить что-либо из чтения DDL-файлов запрещено).Вся структурная эволюция выполняется через центр моделей фронтенда Meta: создание коллекции (collection, подключение родительской таблицы для формирования наследования), регистрация полей (fields), ведение кодировок измерений (сцена/фактор/функция). Регистрация коллекций и полей программно синхронизируется платформой в физические таблицы и подключения наследования — разработчик не пишет ни одного DDL-оператора создания таблиц.
После запуска выпуска из центра моделей конвейер экспортирует схему isahl (pg_dump --schema-only + данные 268 seed-таблиц + seed измерений seed-dimensions.sql), постобрабатывает её до формы чистых CREATE/ALTER, записывает в Alioth/v{version}/ и выполняет полную пересборку с верификацией в выделенной проверочной БД (round-trip структуры + round-trip seed + уникальность uid), а отчёт сохраняется в verify-report.json. Текущий последний выпуск v10.0.44: 1022 таблицы isahl, 1204 рёбер наследования, 268 seed-таблиц с попотабличной round-trip-согласованностью, статус верификации — verified. Конвейер выпуска производит 7 событий прогресса (prepare / schema / isahl_dump / seed_dimensions / manifest / verify / done); уровень строки коллекции декларативно несётся объявлением row_layer (abstract / carry) на стороне модели, а неразрешённая родительская таблица, содержащая строки, блокирует выпуск.
Приземление модели и производная поверхность БД сцеплены одним пакетом: refresh-derived-artifacts.ts — единственная точка входа обновления четырёх производных артефактов fk-index, relation-index, value-domain-columns, dk-projection-tables, уже подключена к reset-db.sh; diff артефактов есть поверхность ревью топологии модели, а защита от удаления обеспечивается гейтом W9.
Бизнес-семантика локализуется трёхмерной координатой: dk_scene (сцена), dk_factor (фактор), dk_function (функция). Код измерения автоматически составляется из кода категории + порядкового символа (например, JC = системное управление). Координаты интерпретируются локально в каждом пространстве имён; каждый API сервиса Service статически привязан к фиксированной тройке координат.
Цепочка построения приложения управляется AppAgent; стандартная последовательность инструментов:
analyze_ontology # требования/прототип → OntologyModel IR (со строгой проверкой полноты пяти доменов)
build_module # flow-plan → module.json (декларация модуля)
build_block # flow-plan → block.json (декларация блока возможностей)
transfer_ontology # онтологическое выравнивание → alignment-graph.json + mapped-entities.json
generate_service_api # онтологическая сущность → бэкенд Service (Rust, статическая привязка координат)
compose_app # сборка модулей → app.json + extensions/*.yaml + артефакты прототипаРазмещение артефактов: Pre-Proc/{ns}/Apps/{app}/ (app.json, extensions, артефакты процесса) и Pre-Proc/{ns}/Sources/Apps/{Modules,Blocks,Services}/ (декларации и код модулей/блоков/сервисов). Форма записей артефакта онтологического отображения (ontology-output.json) проверяется контрактным гейтом, а координаты обязаны быть реальными кодами из БД.
| Слой | Ключевые ограничения |
|---|---|
| Module | Контейнер комбинации Scene/Factor; обязательные поля module.json заполнены полностью; DashboardPage запрещён (прямой переход с корневого пути на страницу списка сущностей) |
| Block | Единица возможностей; ID, на которые ссылаются factors/services, обязаны существовать (для висячих ссылок есть отдельный гейт) |
| Бэкенд Service | Стандартный каркас handlers/models/repositories/services; статическая привязка тройки координат (разные координаты одной таблицы разделяются на разные API); middleware auth запрещён (NGAC централизуется в Gateway); крейт tracing внутри модуля запрещён |
| Фронтенд | Управление состоянием исключительно на Jotai v2; поля измерения по форме «числовое значение + единица измерения одним выбором»; реальная интеграция с бэкендом, mock запрещён; доступ к данным унифицирован через ресурсный transport из @alioth/api (list/get/mutate, конверт распаковывается через items()/unwrap()); селектор ссылок обязан всегда использовать дескриптор ReferenceSelectDescriptor, экстраполяция контракта по типу эндпоинта запрещена |
zc_id_lifecycle_r_*; создавать в сущности собственные столбцы состояния запрещено (flag используется только в строках словаря состояний)dk_function одного из шести префиксов (_f_/_t_ выводятся автоматически, рукописные литералы запрещены)qk_* — указатели в пространство значений (bigint); арифметические операции над ними запрещены, чтение выполняется через разыменование _refsРасширения уровня приложения (constraints / rules / statemachines / workflows) размещаются в Pre-Proc/{ns}/Apps/{app}/extensions/ и загружаются при старте Gateway — это единственная поверхность, приводящая расширения в действие: проверки, правила и процессы можно настраивать без повторной генерации кода.
# Единственная точка входа сборки (feature-гейтинг + изоляция target + автоматическая обработка подписи)
bash scripts/build-ns.sh <NAMESPACE> release # или dev (режим debug)
# Выпуск (синхронизация Apps / seed / .env / apps.json; собственная сборка не выполняется)
bash scripts/deploy/release-to-namespace.sh <NAMESPACE>Артефакты: Deploy/{ns}/bin/{ns}-server (для пространств имён с включённым OpenActivity дополнительно Deploy/{ns}/Open/bin/openactivity-server). При выпуске на стадию production Gateway перезапускается автоматически. Приложения, не привязанные к пространству имён (Meta / SSO), идут через scripts/meta|sso/deploy.sh и попадают в Release/.
Репозиторий принуждает качество через «субстрат исполнения спецификаций»: каждая проверяемая спецификация снабжена скриптом проверки + базовой линией + регистрацией в гейте (229 зарегистрированных гейтов: 137 на стадии commit / 92 на стадии push); библиотека спецификаций содержит 403 живые спецификации capability; каждая клауза MUST/NEVER обязана декларировать место исполнения (id гейта / скрипт / путь теста) через структурированное поле «执行面» (поверхность исполнения); прозаические декларации более не принимаются. Часто встречающиеся позиции:
| Шлюз | Что блокирует | Этап |
|---|---|---|
check-isahl-ddl-boundary | Любая обходная запись структуры isahl | commit |
check-leaf-insert | INSERT не в листовую таблицу / рукописные литералы _f_/_t_ | commit |
check-code-semantics | Запись семантики типов/перечислений в столбец code | commit |
check-ontology-contract | Форма артефакта онтологического отображения / подделка координат | commit |
check-bridge-host-domain | Смещение домена-хоста на левом конце таблицы отношений | commit |
formal-proofs | Падение сборки теорем Lean или наличие заглушки вместо доказательства | push |
check-all (T1/T2) | Согласование версий / соответствие OpenSpec / i18n / DAG сервисов и пр. | push |
Полноценную платформу можно попробовать без локального окружения: https://cosmic-tools.shop/ предоставляет онлайн-обучающую SaaS-версию AliothStudio — облегчённое развёртывание для индивидуальных пользователей (ключевое моделирование, сборка приложений и линия выполнения полностью доступны; корпоративная оркестрация множества пространств имён и конвейер выпуска опущены). Рекомендуемый путь: зарегистрироваться и войти → последовательно пройти практику по главам 2–7 настоящего руководства → самостоятельно проверить артефакты по списку гейтов главы 8.
Сопутствующая литература: «Белая книга теории модели Alioth» — чтобы понять математическую структуру, лежащую в основе всех ограничений настоящего руководства.
© 2025-2026 Hangzhou Yuqi Technology Co., Ltd. (CosmicTools.ltd).