SDK des modules
Construisez la pièce qui manque, dans KeelOps.
Un module est un dossier de JavaScript que KeelOps charge dans son propre processus : il utilise sa connexion, ses droits et son aspect, lit ses données, et apparaît là où l'on travaille — dans le menu, sur la page d'un projet, dans le détail d'une tâche, dans la barre du haut. Pas de second serveur, pas de jetons à distribuer, pas de dépendances à installer. Le SDK est libre (AGPL), et un module déclare dans son manifeste s'il demande l'édition pro.
Ce que vous pouvez construire
Ce dont seule votre équipe a besoin, avec tout le reste de KeelOps autour.
Une page dans le menu
Une entrée avec son icône, une page qui s'ouvre dans l'application et en prend les couleurs, le thème clair ou sombre et la langue du lecteur.
Au cœur du travail
Une commande sur la page d'un projet, un panneau dans le détail d'une tâche, un bouton parmi les pièces jointes d'une offre, une tuile dans la journée : les ancres amènent le module là où il sert.
Vos données
Des tables propres dans la même base, avec leurs migrations, sur les deux moteurs — SQLite et MariaDB. La sauvegarde de KeelOps les emporte.
Rapports et notes de version
Le travail accompli devient un document qui se lit, écrit par des modèles d'IA sur votre serveur : pour les utilisateurs, pour l'administration, pour les commerciaux.
Des outils pour les assistants
Un module offre des outils aux autres, à travers le noyau : c'est ainsi que Claude, ChatGPT et Mistral lisent les données qualité de QABox, avec les droits de la personne qui demande.
Le travail du noyau, avec ses règles
Créer une tâche, joindre un document généré, avoir un groupe de personnes : le module passe par les portes du noyau, avec les droits, les notifications et l'historique habituels.
Un exemple
La carte des tâches : un module dans la page d'un projet.
Elle n'a pas d'entrée dans le menu : elle s'ouvre depuis le menu ⋯ d'un projet. Elle lit les tâches avec les droits de qui regarde, en tire les thèmes du texte avec les modèles locaux, et les dessine en réseau — hiérarchie, fenêtres de temps, qui a travaillé avec qui, et les liens qu'elle suggère d'ajouter.
IA locale
Le travail accompli devient un document qui se lit.
KeelOps sait ce qui a été fait, pour qui, quelle semaine. Un modèle qui tourne sur votre serveur — Ollama, rien ne sort de l'entreprise — le transforme en texte pour ceux qui doivent le lire.
- Des notes de version pour les utilisateurs d'un produit, semaine après semaine, en nouveautés et corrections.
- Le mois d'un client pour l'administration : demandes ouvertes, travail fait, heures par activité, en mots simples.
- La semaine des offres pour les commerciaux : ce qui a bougé, ce qui est bloqué, qui rappeler.
- Les non-conformités du mois pour la qualité, avec les actions qui les ont closes.
Le modèle écrit les phrases ; ce qui entre dans le document et les chiffres, c'est le code qui les décide. Sans modèle le document sort quand même, avec les titres à la place des phrases, et le dit. C'est la même recette que les notes de version que KeelOps génère déjà — à côté, une vraie, envoyée aux utilisateurs d'un produit.
Par où commencer
Un module en vingt lignes.
Un manifeste qui dit qui il est et où il apparaît, et une fonction create(ctx) qui reçoit du noyau la base, la session et les portes, et renvoie ses routes. On ajoute son nom à PLUGINS, on redémarre, et l'entrée est dans le menu.
// plugins/Hello/plugin.mjs
export const manifest = { nome: "Hello", versione: "0.1.0", ui: { voce: "Hello", icona: "puzzle" } };
export async function create(ctx) {
const { json } = await import(`${ctx.sdkDir}/http.mjs`);
return {
routes: [
["GET", /^\/api\/summary$/, async (req, res) => {
const user = await ctx.sessionUser(req); // the real KeelOps session
if (!user) return json(res, 401, { error: "no session" });
const row = await ctx.db.get( // the KeelOps database, read-only
"SELECT COUNT(*) AS open FROM Task t JOIN TaskStatus s ON s.id = t.statusId " +
"WHERE t.assigneeId = ? AND s.isClosed = 0 AND t.deletedAt IS NULL", user.id);
json(res, 200, { name: user.name, open: row.open });
}],
],
staticDir: new URL("./ui", import.meta.url).pathname, // a page, inside the app
};
}Le code et les commentaires des modules sont en anglais, comme la documentation ; les pages se traduisent dans les cinq langues de KeelOps avec un seul mécanisme, fourni par le SDK.
Les règles
Dans le processus, dans les règles.
Une base protégée
Les lectures passent par une connexion qui ne sait pas écrire ; les écritures seulement dans les tables du module, et le filtre lit chaque instruction avant de la laisser passer.
La session KeelOps
Chaque route passe par le garde de session du noyau. Les clients du portail n'atteignent pas les modules, et un module ne montre que ce que la personne peut voir.
Tout par le SDK
Pas d'accès direct à la base, à l'environnement du serveur ou aux modèles : un test du noyau lit les sources de chaque module et s'arrête sur un import interdit.
Il s'active et se désactive
Depuis la page Système, l'administrateur voit la version, la licence et la description de chaque module, et le désactive sans redémarrer. Désactivé, il disparaît ; ses données restent.
La documentation.
Des guides pas à pas, des exemples, les règles et la référence complète de l'API, en onze chapitres. Elle est en anglais, la langue de ceux qui écrivent du code.