AliothStudio se compone de dos cadenas con responsabilidades separadas; comprender sus límites es la premisa para usar la plataforma correctamente:
| Cadena | Responsabilidad | Impulsor | Producto |
|---|---|---|---|
| Cadena de publicación del modelo | Evolución estructural de la base de datos (tablas/columnas/herencia/codificación de dimensiones) | Centro de modelos Meta (canal manual) | Paquete de publicación Alioth/v* (DDL · semillas · contrato legible por máquina · informe de verificación) |
| Cadena de construcción de aplicaciones | Ensamblar aplicaciones de negocio sobre la base congelada | Agente AppAgent + desarrolladores | Configuración de la aplicación, backend de Service, frontend de módulos, paquete de despliegue Deploy/{ns} |
| Dependencia | Uso |
|---|---|
| PostgreSQL 14+ | Base de datos (el modelo v10.0 es una estructura de herencia de tablas) |
| mise | Punto de entrada unificado para tareas y entornos (mise run <task>) |
| Rust toolchain / pnpm / bun | Compilación del backend, compilación del frontend, cadena de herramientas de scripts |
# Inicialización de la base de datos de desarrollo (reproducida desde la instantánea de publicación; hace DROP y recrea la base destino, solo para aliothstudio_dev)
bash scripts/db/reset-db.sh --dev
# Plataforma Meta (gestión de modelos + AppAgent): backend :4949, frontend :49494
mise run meta
# Entorno de desarrollo del espacio de nombres (Gateway + SSO), {ns} ∈ alioth | wz | avic | cosmic | se | mat
mise run dev:{ns}aliothstudio ← preproducción aliothstudio_pre → desarrollo aliothstudio_dev → pruebas aliothstudio_test. El entorno está vinculado obligatoriamente con DATABASE_URL; todas las consultas de esquema pasan siempre por cd Meta/backend && mise run schema-info -- <command> (la base de datos es la única fuente de verdad; se prohíbe inferir leyendo archivos DDL).Toda la evolución estructural se realiza a través del centro de modelos del frontend Meta: crear colecciones (collection, enganchando una tabla padre para formar la herencia), registrar campos (fields) y mantener la codificación de dimensiones (escena/factor/función). El registro de colecciones y campos se sincroniza programáticamente como tablas físicas y enganches de herencia: el desarrollador no escribe ningún DDL de creación de tablas.
Cuando el centro de modelos lanza una publicación, la cadena de procesamiento exporta el esquema isahl (pg_dump --schema-only + los datos de 268 tablas semilla + la semilla de dimensiones seed-dimensions.sql), lo posprocesa a forma pura CREATE/ALTER, lo escribe en Alioth/v{version}/ y realiza una reconstrucción y verificación completas en una base de datos de verificación dedicada (ida y vuelta de estructura + ida y vuelta de semillas + unicidad de uid), con el informe volcado a disco en verify-report.json. La publicación más reciente actual es v10.0.44: 1022 tablas isahl, 1204 aristas de herencia, 268 tablas semilla con ida y vuelta tabla a tabla consistente, estado de verificación verified. El pipeline de publicación produce 7 eventos de progreso (prepare / schema / isahl_dump / seed_dimensions / manifest / verify / done); el nivel de fila de las filas de colección lo porta la declaración row_layer (abstract / carry) del lado del modelo, y que una tabla padre no adjudicada contenga filas bloquea la publicación.
El aterrizaje del modelo y la superficie de derivación de la base de datos se acoplan en el mismo lote: refresh-derived-artifacts.ts es el único punto de entrada de refresco de los cuatro productos derivados fk-index, relation-index, value-domain-columns y dk-projection-tables, y ya está integrado en reset-db.sh; el diff de los productos es la superficie de revisión de la topología del modelo, y la protección contra su eliminación la garantiza la puerta W9.
La semántica de negocio se localiza mediante coordenadas tridimensionales: dk_scene (escena), dk_factor (factor), dk_function (función). El código de dimensión se compone automáticamente con el código de categoría + el símbolo del número de orden (por ejemplo JC = gestión del sistema). Las coordenadas se interpretan localmente según el espacio de nombres; cada API de un Service vincula estáticamente una terna fija de coordenadas.
La cadena de construcción de aplicaciones está impulsada por AppAgent; secuencia estándar de herramientas:
analyze_ontology # requisitos/prototipo → IR OntologyModel (con validación dura de completitud de los cinco dominios)
build_module # flow-plan → module.json (declaración del módulo)
build_block # flow-plan → block.json (declaración del bloque de capacidades)
transfer_ontology # alineación ontológica → alignment-graph.json + mapped-entities.json
generate_service_api # entidad ontológica → backend de Service (Rust, vinculación estática de coordenadas)
compose_app # ensamblaje de módulos → app.json + extensions/*.yaml + productos del prototipoUbicación de los productos: Pre-Proc/{ns}/Apps/{app}/ (app.json, extensions, productos del flujo) y Pre-Proc/{ns}/Sources/Apps/{Modules,Blocks,Services}/ (declaraciones y código de módulos/bloques/servicios). La forma de las entradas del producto de mapeo ontológico (ontology-output.json) está sujeta a la validación de una puerta de contratos, y las coordenadas deben ser códigos reales de la base de datos.
| Capa | Restricciones clave |
|---|---|
| Module | Contenedor de combinación Scene/Factor; los campos obligatorios de module.json deben estar completos; se prohíbe DashboardPage (salto directo desde la ruta raíz a la página de listado de entidades) |
| Block | Unidad de capacidad; los ID referenciados por factors/services deben existir (las referencias huérfanas tienen una puerta de control específica) |
| Backend de Service | Esqueleto estándar handlers/models/repositories/services; vinculación estática de la terna de coordenadas (la misma tabla con coordenadas distintas se separa en APIs distintas); se prohíbe el middleware auth (NGAC unificado en el Gateway); se prohíbe el crate tracing dentro del módulo |
| Frontend | Gestión de estado siempre con Jotai v2; los campos de medida siguen el formato «valor + unidad de selección única»; integración contra el backend real, se prohíbe el mock; el acceso a datos se unifica a través del transport de nivel de recurso de @alioth/api (list/get/mutate, el sobre se desenvuelve con items()/unwrap()); el selector de referencias debe usar siempre el descriptor ReferenceSelectDescriptor y tiene prohibido extrapolar el contrato a partir del tipo de endpoint |
zc_id_lifecycle_r_*; se prohíbe que la entidad cree su propia columna de estado (flag se usa solo en las filas del diccionario de estados)dk_function de uno de los seis prefijos (_f_/_t_ se derivan automáticamente; se prohíbe escribir literales a mano)qk_* son punteros al espacio de valores (bigint); se prohíbe operar aritméticamente sobre ellas y la lectura pasa por la resolución _refsLas extensiones a nivel de aplicación (constraints / rules / statemachines / workflows) se colocan en Pre-Proc/{ns}/Apps/{app}/extensions/ y el Gateway las carga al arrancar; es la única superficie de activación de las extensiones: se pueden ajustar validaciones, reglas y flujos sin necesidad de regenerar código.
# Único punto de entrada de compilación (feature gating + aislamiento de target + tratamiento automático de firmas)
bash scripts/build-ns.sh <NAMESPACE> release # o dev (modo debug)
# Publicación (sincronización de Apps / seed / .env / apps.json; no compila por sí misma)
bash scripts/deploy/release-to-namespace.sh <NAMESPACE>Productos: Deploy/{ns}/bin/{ns}-server (los espacios de nombres con OpenActivity habilitado disponen además de Deploy/{ns}/Open/bin/openactivity-server). Al publicar en la etapa production se reinicia automáticamente el Gateway. Las aplicaciones que no son de espacio de nombres (Meta / SSO) siguen scripts/meta|sso/deploy.sh y aterrizan en Release/.
El repositorio impone la calidad mediante un «sustrato de ejecución de especificaciones»: cada especificación verificable cuenta con un script de comprobación + una línea base + un registro de puerta de control (actualmente 229 puertas registradas: 137 en commit / 92 en push). La biblioteca de especificaciones contiene 403 especificaciones vivas de capability; cada cláusula MUST/NEVER debe declarar su punto de ejecución (id de puerta / script / ruta de test) mediante el campo estructurado «执行面» (superficie de ejecución); las declaraciones en prosa ya no se admiten. Elementos de contacto frecuente:
| Puerta de control | Objeto bloqueado | Fase |
|---|---|---|
check-isahl-ddl-boundary | Cualquier escritura estructural isahl que sortee el canal previsto | commit |
check-leaf-insert | INSERT que no aterriza en la tabla hoja / literales _f_/_t_ escritos a mano | commit |
check-code-semantics | Escritura de semántica de tipos/enumeraciones en la columna code | commit |
check-ontology-contract | Forma del producto de mapeo ontológico / falsificación de coordenadas | commit |
check-bridge-host-domain | Desalineación del dominio anfitrión en el extremo izquierdo de la tabla de relación | commit |
formal-proofs | Fallo en la compilación de los teoremas Lean o presencia de marcadores de prueba pendientes | push |
check-all (T1/T2) | Alineación de versiones / conformidad con OpenSpec / i18n / DAG de Services, etc. | push |
Puede experimentar la plataforma completa sin entorno local: https://cosmic-tools.shop/ ofrece la edición en línea de aprendizaje práctico SaaS de AliothStudio, un despliegue simplificado para usuarios individuales (el modelado central, el ensamblaje de aplicaciones y la línea de ejecución están completos y disponibles; se omiten la orquestación empresarial multi-espacio de nombres y la cadena de publicación). Ruta recomendada: registrarse y entrar → practicar en orden siguiendo los capítulos 2 a 7 de este manual → autoverificar los productos con la lista de puertas de control del capítulo 8.
Bibliografía complementaria: «Libro blanco de la teoría del modelo Alioth» — para comprender la estructura matemática que subyace a todas las restricciones de este manual.
© 2025-2026 Hangzhou Yuqi Technology Co., Ltd. (CosmicTools.ltd).