ObjectOS
Erstellen

Pakete

Die Organisationseinheit in ObjectOS — versioniert, installierbar, teilbar.

Pakete

Alles, was Sie in ObjectOS erstellen, lebt in einem Paket: einem versionierten, in sich geschlossenen Bündel von Metadaten. Pakete sind die Einheit, an der der AI Builder arbeitet, die Einheit, die der marketplace ausliefert, und die Einheit, gegen die ObjectOS Updates verfolgt.

Was in einem Paket steckt

com.acme.crm@1.2.0
├── manifest          id, version, namespace, dependencies
├── objects/          *.object.ts, *.state.ts, *.hook.ts
├── views/            *.view.ts, *.page.ts, *.form.ts
├── actions/          *.action.ts
├── flows/            *.flow.ts, *.approval.ts
├── agents/           *.agent.ts, *.skill.ts
├── permissions/      *.permission.ts
├── sharing/          *.sharing.ts
├── translations/     en.ts, zh-CN.ts, ...
├── apps/             *.app.ts  (navigation)
└── data/             defineDataset(...) seed

Jedes Metadaten-Artefakt (Objekt, Aktion, Flow, …) gehört zu genau einem Paket. Die Paket-id ist reverse-DNS (com.acme.crm, org.mycompany.helpdesk), und das Namespace-Präfix (crm_, hd_) verhindert, dass Tabellen- / Objektnamen über mehrere im selben Tenant installierte Pakete hinweg kollidieren.

Ein Paket erstellen

Über den AI Builder

"Starte ein neues Paket für unser internes CRM, namespace crm."

Die KI ruft create_package und set_active_package auf. Von da an landet jedes Objekt / Feld / jede Aktion, die Sie beschreiben, in crm.

Über die CLI

os init my-crm -t app
cd my-crm
# manifest lives in the `manifest:` block of ./objectstack.config.ts
pnpm dev

Über die Console

Console → Packages → New Package — Name, id, Version, namespace.

Aktives Paket

Im AI Builder trägt eine Konversation ein aktives Paket — den Standard- Container für neue Metadaten. Die KI setzt es mit dem Tool set_active_package, wenn Sie etwas sagen wie "Wechsle zu com.acme.helpdesk." Über die CLI ist das aktive Paket einfach dasjenige, das in der objectstack.config.ts des Projekts deklariert ist (der manifest:-Block).

Versionierung

Pakete verwenden semver. Dieselben Regeln wie die Runtime — siehe Changelog & Versioning.

Das Anheben einer Version ändert nichts, bis Sie veröffentlichen. Die Runtime verfolgt installed_version pro Tenant pro Paket, und der marketplace zeigt ein "Update available"-Badge an, wenn der Katalog eine neuere Version hat.

Abhängigkeiten

Pakete können von anderen Paketen abhängen:

{
  "id": "com.acme.helpdesk",
  "version": "0.3.0",
  "dependencies": {
    "com.acme.crm": "^1.0.0",
    "sys.feeds":   "*"
  }
}

Die Runtime löst Abhängigkeiten bei der Installation auf. Wenn com.acme.crm nicht installiert ist, schlägt die Helpdesk-Installation mit einem klaren Fehler fehl.

Systempakete (sys.*) sind immer vorhanden — feeds, attachments, audit, identity usw.

Veröffentlichen

os compile                     # → dist/objectstack.json
os package publish             # → ObjectStack cloud catalog

os package publish lädt das kompilierte manifest in die Cloud-Control-Plane hoch, die durch OS_CLOUD_URL konfiguriert und mit OS_CLOUD_API_KEY authentifiziert wird. Für private / luftgekapselte Distribution überspringen Sie das Veröffentlichen und übergeben das kompilierte dist/objectstack.json direkt an die Zielinstallation (siehe Installieren weiter unten). Siehe Marketplace.

Installieren

PfadWie
ConsoleMarketplace-Tab → Paket auswählen → Install
RESTPOST /api/v1/marketplace/install-local (Body: { packageId, versionId? })
LuftgekapseltDas kompilierte dist/objectstack.json-Artefakt einhängen (siehe Air-gapped)

Die Installation führt die Metadaten des Pakets in den laufenden Kernel zusammen, registriert seine Objekte bei ObjectQL und sät bei der ersten Installation initiale Daten — kein Neustart nötig. Zwischengespeicherte Installationen werden beim nächsten Boot erneut registriert und überstehen so Prozess-Neustarts.

Deinstallieren

Beim Deinstallieren wird das zwischengespeicherte manifest des Pakets entfernt, sodass es beim nächsten Boot nicht mehr erneut registriert wird. Da die Objektregistrierung additiv ist, ist ein Kernel-Neustart erforderlich, um die Objekte eines bereits laufenden Pakets vollständig zu entladen. Daten werden standardmäßig behalten, sodass Sie erneut installieren und fortfahren können.

Paketübergreifende Konventionen

Um Kollisionen zu vermeiden, wenn viele Pakete koexistieren:

ArtefaktKonvention
ObjektnamenImmer mit Präfix: crm_account, hd_ticket
AktionsnamenMit Präfix: crm_assign_owner, hd_close_ticket
Flow-NamenMit Präfix: hd_overdue_alert
ÜbersetzungsschlüsselUnter dem namespace eingeordnet: crm.account.label
Seed-externalId<prefix>:<key>, z. B. crm:demo-account-1
SystemnamenReserviert: sys_* (niemals in benutzerdefinierten Paketen verwenden)

Sowohl die CLI als auch der AI Builder erzwingen dies bei der Erstellung.

Systempakete

Die Runtime liefert eine kleine Reihe stets vorhandener Pakete mit, die polymorphe Dienste bereitstellen:

PaketStellt bereit
sys.identitysys_user, sys_organization, sys_member, Sessions, API-Keys
sys.feedssys_comment, sys_activity, sys_attachment
sys.auditsys_audit_log
sys.filessys_file
sys.aiai_conversations, ai_pending_actions
sys.settingssys_setting

Sie aktivieren sie über enable: { feeds: true, trackHistory: true, … } an Ihren Objekten — siehe Data Model.

Wie es weitergeht

On this page