L'unité d'organisation dans ObjectOS — versionnée, installable, partageable.

Packages

Tout ce que vous construisez dans ObjectOS réside dans un package : un ensemble de métadonnées autonome et versionné. Le package est l'unité sur laquelle travaille l'AI Builder, l'unité que distribue le marketplace, et l'unité dont ObjectOS suit les mises à jour.

Contenu d'un package

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

Chaque artefact de métadonnées (object, action, flow, …) appartient à exactement un package. L'id du package est en reverse-DNS (com.acme.crm, org.mycompany.helpdesk) et le préfixe de namespace (crm_, hd_) empêche les noms de tables / d'objets d'entrer en collision entre les packages installés dans le même tenant.

Créer un package

Depuis l'AI Builder

« Démarre un nouveau package pour notre CRM interne, namespace crm. »

L'IA appelle create_package et set_active_package. À partir de là, chaque object / champ / action que vous décrivez est placé dans crm.

Depuis la CLI

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

Depuis la Console

Console → Packages → New Package — nom, id, version, namespace.

Package actif

Dans l'AI Builder, une conversation porte un package actif — le conteneur par défaut pour les nouvelles métadonnées. L'IA le définit avec l'outil set_active_package lorsque vous dites par exemple « Bascule vers com.acme.helpdesk. » Depuis la CLI, le package actif est simplement celui déclaré dans le fichier objectstack.config.ts du projet (le bloc manifest:).

Versionnement

Les packages utilisent le semver. Mêmes règles que le runtime — voir Changelog & Versioning.

Incrémenter une version ne change rien tant que vous ne publiez pas. Le runtime suit installed_version par tenant et par package, et le marketplace affiche un badge « Update available » lorsque le catalogue contient une version plus récente.

Dépendances

Les packages peuvent dépendre d'autres packages :

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

Le runtime résout les dépendances à l'installation. Si com.acme.crm n'est pas installé, l'installation du helpdesk échoue avec une erreur explicite.

Les packages système (sys.*) sont toujours présents — feeds, pièces jointes, audit, identité, etc.

Publication

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

os package publish téléverse le manifeste compilé vers le plan de contrôle cloud configuré par OS_CLOUD_URL, authentifié avec OS_CLOUD_API_KEY. Pour une distribution privée / air-gapped, ignorez la publication et transmettez directement le dist/objectstack.json compilé à l'installation cible (voir Installation ci-dessous). Voir Marketplace.

Installation

Méthode	Comment
Console	Onglet Marketplace → choisir le package → Install
REST	`POST /api/v1/marketplace/install-local` (corps : `{ packageId, versionId? }`)
Air-gapped	Monter l'artefact `dist/objectstack.json` compilé (voir Air-gapped)

L'installation fusionne les métadonnées du package dans le kernel en service, enregistre ses objects auprès d'ObjectQL et amorce les données initiales lors de la première installation — aucun redémarrage requis. Les installations en cache sont réenregistrées au prochain démarrage, ce qui leur permet de survivre aux redémarrages de processus.

Désinstallation

La désinstallation supprime le manifeste mis en cache du package afin qu'il ne soit plus réenregistré au prochain démarrage. Comme l'enregistrement des objects est additif, un redémarrage du kernel est nécessaire pour décharger complètement les objects d'un package déjà en cours d'exécution. Les données sont conservées par défaut, ce qui vous permet de réinstaller et de reprendre.

Conventions inter-packages

Pour éviter les collisions lorsque de nombreux packages coexistent :

Artefact	Convention
Noms d'objects	Toujours préfixés : `crm_account`, `hd_ticket`
Noms d'actions	Préfixés : `crm_assign_owner`, `hd_close_ticket`
Noms de flows	Préfixés : `hd_overdue_alert`
Clés de traduction	Cadrées sous le namespace : `crm.account.label`
`externalId` des seeds	`<prefix>:<key>`, ex. `crm:demo-account-1`
Noms système	Réservés : `sys_*` (à ne jamais utiliser dans les packages personnalisés)

La CLI et l'AI Builder appliquent tous deux ces règles à la création.

Packages système

Le runtime fournit un petit ensemble de packages toujours présents qui offrent des services polymorphes :

Package	Fournit
`sys.identity`	`sys_user`, `sys_organization`, `sys_member`, sessions, clés API
`sys.feeds`	`sys_comment`, `sys_activity`, `sys_attachment`
`sys.audit`	`sys_audit_log`
`sys.files`	`sys_file`
`sys.ai`	`ai_conversations`, `ai_pending_actions`
`sys.settings`	`sys_setting`

Vous les activez via enable: { feeds: true, trackHistory: true, … } sur vos objects — voir Data Model.

Pour aller plus loin

Marketplace — distribuer des packages à d'autres tenants
Data Model — ce qui réside à l'intérieur d'un package
Commandes os package — référence CLI complète

Packages

On this page