AliothStudio besteht aus zwei Ketten mit getrennten Zuständigkeiten; das Verständnis ihrer Grenze ist die Voraussetzung für die korrekte Nutzung der Plattform:
| Kette | Zuständigkeit | Treiber | Ergebnis |
|---|---|---|---|
| Modellveröffentlichungskette | strukturelle Evolution des Datenfundaments (Tabellen/Spalten/Vererbung/Dimensionscodes) | Meta-Modellzentrum (manueller Kanal) | Alioth/v*-Veröffentlichungspaket (DDL · Seed · maschinenlesbarer Vertrag · Verifikationsbericht) |
| Anwendungserstellungskette | Montage von Geschäftsanwendungen auf dem eingefrorenen Fundament | AppAgent-Agent + Entwickler | Anwendungskonfiguration, Service-Backend, Modul-Frontend, Deploy/{ns}-Bereitstellungspaket |
| Abhängigkeit | Zweck |
|---|---|
| PostgreSQL 14+ | Datenfundament (Modell v10.0 als Tabellenvererbungsstruktur) |
| mise | einheitlicher Einstieg für Aufgaben und Umgebung (mise run <task>) |
| Rust-Toolchain / pnpm / bun | Backend-Build, Frontend-Build, Skript-Toolchain |
# Initialisierung der Entwicklungsdatenbank (Replay aus dem Veröffentlichungs-Snapshot; führt DROP und Neuaufbau der Zieldatenbank aus, nur für aliothstudio_dev)
bash scripts/db/reset-db.sh --dev
# Meta-Plattform (Modellverwaltung + AppAgent): Backend :4949, Frontend :49494
mise run meta
# Entwicklungsumgebung des Namespace (Gateway + SSO), {ns} ∈ alioth | wz | avic | cosmic | se | mat
mise run dev:{ns}aliothstudio ← Pre-Prod aliothstudio_pre → Entwicklung aliothstudio_dev → Test aliothstudio_test. Umgebung und DATABASE_URL sind zwingend aneinander gebunden; Schema-Abfragen laufen ausnahmslos über cd Meta/backend && mise run schema-info -- <command> (die DB ist die einzige Quelle der Wahrheit; das Ableiten aus DDL-Dateien ist verboten).Die gesamte strukturelle Evolution erfolgt über das Modellzentrum im Meta-Frontend: Anlegen von Collections (collection, Anhängen an eine Elterntabelle zur Bildung von Vererbung), Registrieren von Feldern (fields), Pflege der Dimensionscodes (Szene/Faktor/Funktion). Die Registrierung von Collections und Feldern wird von der Plattform programmatisch mit physischen Tabellen und Vererbungsanhängen synchronisiert — Entwickler schreiben keinerlei DDL zum Erzeugen von Tabellen.
Nach dem Start einer Veröffentlichung im Modellzentrum exportiert die Pipeline das isahl-Schema (pg_dump --schema-only + Daten von 268 Seed-Tabellen + die Dimensions-Seeds seed-dimensions.sql), verarbeitet es zu einer reinen CREATE/ALTER-Form, schreibt es nach Alioth/v{version}/ und führt in einer dedizierten Verifikationsdatenbank einen vollständigen Neuaufbau mit Verifikation durch (Struktur-Roundtrip + Seed-Roundtrip + uid-Eindeutigkeit); der Bericht wird als verify-report.json abgelegt. Die aktuell neueste Veröffentlichung v10.0.44: 1022 isahl-Tabellen, 1204 Vererbungskanten, 268 Seed-Tabellen tabellenweise roundtrip-konsistent, Verifikationsstatus verified. Die Veröffentlichungspipeline erzeugt 7 Fortschrittsereignisse (prepare / schema / isahl_dump / seed_dimensions / manifest / verify / done); die Zeilenebenen-Hierarchie der Collections wird durch die modellseitige Deklaration row_layer (abstract / carry) getragen — hält eine nicht adjudizierte Elterntabelle Zeilen, wird die Veröffentlichung blockiert.
Modellinkarnation und abgeleitete DB-Fläche sind im selben Batch gekoppelt: refresh-derived-artifacts.ts ist der einzige Aktualisierungseinstieg für die vier abgeleiteten Artefakte fk-index, relation-index, value-domain-columns, dk-projection-tables und ist bereits in reset-db.sh eingebunden; der Diff der Artefakte ist die Review-Fläche der Modelltopologie, der Schutz vor Entfernung wird durch das Gate W9 garantiert.
Die Geschäftssemantik wird über dreidimensionale Koordinaten lokalisiert: dk_scene (Szene), dk_factor (Faktor), dk_function (Funktion). Der Dimensionscode wird automatisch aus Kategoriecode + laufendem Symbol zusammengesetzt (etwa JC = Systemverwaltung). Koordinaten werden pro Namespace lokal interpretiert; jede API eines Service bindet statisch ein festes Koordinatentripel.
Die Anwendungserstellungskette wird vom AppAgent angetrieben; die Standardwerkzeugfolge lautet:
analyze_ontology # Anforderung/Prototyp → OntologyModel-IR (mit harter Prüfung der Vollständigkeit der fünf Domänen)
build_module # flow-plan → module.json (Moduldeklaration)
build_block # flow-plan → block.json (Deklaration des Fähigkeitsblocks)
transfer_ontology # Ontologieausrichtung → alignment-graph.json + mapped-entities.json
generate_service_api # Ontologieentität → Service-Backend (Rust, statische Koordinatenbindung)
compose_app # Modulmontage → app.json + extensions/*.yaml + Prototyp-ArtefakteAblage der Artefakte: Pre-Proc/{ns}/Apps/{app}/ (app.json, extensions, Prozessartefakte) und Pre-Proc/{ns}/Sources/Apps/{Modules,Blocks,Services}/ (Deklarationen und Code für Module/Blocks/Services). Die Eintragsform der Ontologie-Abbildungsartefakte (ontology-output.json) unterliegt der Prüfung durch das Vertrags-Gate; Koordinaten müssen echte Codes aus der DB sein.
| Ebene | Zentrale Vorgaben |
|---|---|
| Module | Kombinationscontainer für Scene/Factor; die Pflichtfelder in module.json müssen vollständig sein; DashboardPage ist verboten (direkter Sprung von der Wurzelroute auf die Entitätslistenseite) |
| Block | Fähigkeitseinheit; die von factors/services referenzierten IDs müssen existieren (verwaiste Verweise haben ein eigenes Gate) |
| Service-Backend | Standardskelett handlers/models/repositories/services; statische Bindung des Koordinatentripels (gleiche Tabelle mit unterschiedlichen Koordinaten wird in getrennte APIs aufgeteilt); auth-Middleware ist verboten (das Gateway übernimmt NGAC zentral); das tracing-Crate ist innerhalb von Modulen verboten |
| Frontend | Zustandsverwaltung ausnahmslos mit Jotai v2; Messfelder im Format „Zahlenwert + Einheitenauswahl“; Abgleich mit dem echten Backend, Mocking ist verboten; der Datenzugriff läuft einheitlich über den Ressourcen-Transport von @alioth/api (list/get/mutate, die Envelope wird per items()/unwrap() entpackt); der Referenz-Selektor muss stets den ReferenceSelectDescriptor verwenden, das Extrapolieren des Vertrags aus dem Endpunkt-Typ ist untersagt |
zc_id_lifecycle_r_*-Relationstabellen geschrieben; selbst angelegte Statusspalten an der Entität sind verboten (flag wird nur von Zeilen des Statuswörterbuchs verwendet)dk_function aus einem der sechs Präfixe angeben (_f_/_t_ werden automatisch abgeleitet; handschriftliche Literale sind verboten)qk_*-Spalten sind Zeiger in den Wertraum (bigint); Arithmetik darauf ist verboten, gelesen wird über die Auflösung mit _refsErweiterungen auf Anwendungsebene (constraints / rules / statemachines / workflows) liegen unter Pre-Proc/{ns}/Apps/{app}/extensions/ und werden beim Start des Gateway geladen; sie sind die einzige wirksame Steuerungsfläche für Erweiterungen — Validierungen, Regeln und Abläufe lassen sich anpassen, ohne Code neu zu generieren.
# Einziger Build-Einstieg (Feature-Gating + Target-Isolation + automatische Signaturbehandlung)
bash scripts/build-ns.sh <NAMESPACE> release # oder dev (Debug-Modus)
# Veröffentlichung (Synchronisation von Apps / seed / .env / apps.json; kein eigener Build)
bash scripts/deploy/release-to-namespace.sh <NAMESPACE>Artefakte: Deploy/{ns}/bin/{ns}-server (Namespaces mit aktiviertem OpenActivity haben zusätzlich Deploy/{ns}/Open/bin/openactivity-server). Bei einer Veröffentlichung in die Produktionsstufe wird das Gateway automatisch neu gestartet. Anwendungen außerhalb eines Namespace (Meta / SSO) laufen über scripts/meta|sso/deploy.sh und landen in Release/.
Das Repository erzwingt Qualität über ein „Substrat zur Durchsetzung von Spezifikationen“: Jede prüfbare Spezifikation hat ein Prüfskript + eine Baseline + eine Gate-Registrierung (229 registrierte Gates: 137 in der Commit-Phase / 92 in der Push-Phase). Die Spezifikationsbibliothek enthält 403 lebende Capability-Spezifikationen; jede MUST/NEVER-Klausel muss ihren Ausführungsort (Gate-ID / Skript / Testpfad) über das strukturierte Feld „执行面" (Ausführungsoberfläche) deklarieren; Prosa-Deklarationen werden nicht mehr durchgelassen. Häufig berührte Einträge:
| Gate | Abgefangenes Objekt | Stufe |
|---|---|---|
check-isahl-ddl-boundary | jedes umgehende Schreiben in die isahl-Struktur | commit |
check-leaf-insert | INSERT ohne Blatt-Tabelle / handschriftliche _f_/_t_-Literale | commit |
check-code-semantics | Schreiben von Typ-/Enum-Semantik in die code-Spalte | commit |
check-ontology-contract | Form der Ontologie-Abbildungsartefakte / gefälschte Koordinaten | commit |
check-bridge-host-domain | falsch platzierte Host-Domäne am linken Ende der Relationstabelle | commit |
formal-proofs | fehlgeschlagener Lean-Theorem-Build oder Beweislücken | push |
check-all (T1/T2) | Versionsabgleich / OpenSpec-Konformität / i18n / Service-DAG u. a. | push |
Die vollständige Plattform lässt sich auch ohne lokale Umgebung erproben: https://cosmic-tools.shop/ bietet eine Online-SaaS-Lernedition von AliothStudio — eine verschlankte Bereitstellung für einzelne Nutzer (Kernmodellierung, Anwendungsmontage und Laufzeitlinie sind vollständig nutzbar; die unternehmensweite Orchestrierung mehrerer Namespaces und die Veröffentlichungspipeline entfallen). Empfohlener Weg: registrieren und einsteigen → die Kapitel 2–7 dieses Handbuchs der Reihe nach praktisch durchlaufen → die Artefakte mit der Gate-Liste aus Kapitel 8 selbst prüfen.
Begleitliteratur: „Whitepaper zur Alioth-Modelltheorie“ — zum Verständnis der mathematischen Struktur hinter allen Vorgaben dieses Handbuchs.
© 2025-2026 Hangzhou Yuqi Technology Co., Ltd. (CosmicTools.ltd).