Un seul socle pour tous vos projets sur mesure.
Comptes, clients, devis, factures, planning, stock : les mêmes fondations à chaque projet. Cortex les porte une fois. Vous n'écrivez que ce qui distingue le vôtre.
-
Le projet reçoit sa clé.
Un espace isolé, ses comptes, sa clé d'API. Ses données ne croisent jamais celles d'un autre.
-
Il allume ses modules.
Seuls ceux-là existent pour lui : écrans, routes, documentation.
-
Vous écrivez l'écran.
Votre application, ou votre agent, appelle l'API. Les règles restent dans Cortex.
On allume ce dont le projet a besoin.
Le coiffeur n'a pas de stock, le loueur n'a pas de chantier. Un module éteint n'existe pas pour le projet : pas d'écran, pas de route d'API. Essayez.
3 modules allumés
200GET /api/v1/appointments
403GET /api/v1/orders · feature_disabled
Branché au dehors iCalendarCourriel
Les règles sont derrière l'API. L'agent n'écrit que l'écran.
Chaque projet exporte son kit, généré depuis sa configuration réelle. Il n'est pas écrit à la main, donc il ne peut pas être périmé.
Moins de jetons. Le manifeste et le schéma sont réduits à ce que ce client possède. Il n'y a pas de reste à explorer.
Moins d'erreurs. Les corps de requête sont décrits d'après les validateurs eux-mêmes. La forme publiée est celle qui refuse une requête mal formée.
Rien à réécrire. Numérotation continue, factures immuables, transitions de statut, isolation des données : tout cela vit dans Cortex.
-
/llms.txtLe point d'entrée public : quoi lire, dans quel ordre. Généré depuis la liste des modules.
-
/api/v1/manifestCe que ce client a réellement : modules ouverts, statuts, transitions, événements, champs propres à sa maison. ?format=md pour la version rédigée.
-
/api/v1/openapi.jsonLe schéma OpenAPI 3.1. Présenté avec la clé du client, il ne décrit que ses routes.
Écrivez ce qui distingue votre projet. Rien d'autre.
Le moteur tourne et l'API est documentée. Un agent commence par /llms.txt : il y trouve quoi lire, et dans quel ordre.