OpenLore

📜 OpenLore

Sponsorisé par

Servez votre documentation aux agents IA via SSH.

OpenLore est une base de connaissances minimale, extensible et native pour les agents, qui maintient un contexte partagé à jour et inspectable.

---

À propos

Les agents de codage IA savent déjà explorer des fichiers avec ls, cat, grep, find, les pipes et les boucles shell. OpenLore leur offre la même interface via SSH, adossée à votre documentation au lieu d'une machine réelle.

Agent ──SSH or MCP──▶ OpenLore ──▶ docs, knowledge, and artifacts

Il démarre comme un serveur de documentation en lecture seule, à binaire unique et sans configuration. Lorsque vous avez besoin d'une base de connaissances en direct, vous pouvez ajouter un accès limité par identité, une publication contrôlée, des écritures atomiques, une validation et une approbation humaine sans changer la façon dont les agents lisent ou naviguent dans le contenu.

Stocker et récupérer du Markdown

Placez de la documentation, des runbooks, du contexte de projet ou des notes rédigées par des agents dans des fichiers Markdown ordinaires. Il n'y a pas de pipeline d'ingestion : pointez OpenLore vers un répertoire et il sert directement la hiérarchie existante. Organisez les documents avec des dossiers, reliez-les avec des liens Markdown standard et regroupez-les en docsets lorsque différentes personnes ou agents ont besoin d'accès différents. OpenLore est en lecture seule par défaut ; activez l'écriture lorsque vous souhaitez que les agents créent et mettent à jour également du Markdown.

Démarrage rapide

Le chemin le plus rapide est de laisser votre agent configurer OpenLore :

# Teach your agent how to install, configure, and bundle OpenLore
ssh openlore.sh teach | your-agent-cli

# Add documentation access instructions to AGENTS.md
ssh openlore.sh agents >> AGENTS.md

Ou installez-le et exécutez-le directement :

go install github.com/aakarim/go-openlore/cmd/openlore@latest

openlore ./docs

ssh -p 2222 localhost
ssh -p 2222 localhost "grep -r 'authentication' /docs"

Par défaut, cela démarre :

• SSH sur localhost:2222
• la vue web destinée aux humains sur http://localhost:8080
• MCP sur HTTP sur http://localhost:8080/mcp

Consultez Installation pour plus de façons d'installer et d'empaqueter OpenLore.

Fonctionnalités

• Récupération native pour les agents — Les agents utilisent les outils shell et les schémas de composition qu'ils connaissent déjà au lieu d'apprendre une API de récupération sur mesure.
• Une surface de connaissances, plusieurs transports — Servez le même système de fichiers virtuel via SSH, SFTP/SSHFS, MCP et une vue web conviviale.
• Connaissances vivantes et gouvernées — Gardez le contenu en lecture seule, autorisez une publication limitée, ou activez les écritures complètes par docset. Les écritures sont atomiques, conscientes des conflits et peuvent exiger une approbation humaine.
• Vues limitées par identité — Donnez à chaque personne ou agent uniquement les docsets dont il a besoin, avec des autorisations ro, publish et rw basées sur les rôles, des alias de chemins et des répertoires personnels privés.
• Sûr par construction — Le shell est un interpréteur Go en mémoire, pas un véritable shell de système d'exploitation. Il n'y a pas d'échappement shell, d'exécution de processus arbitraire ni d'accès réseau ambiant dans une session normale.
• Paquets de connaissances portables — Intégrez des documents dans un binaire autonome, créez des paquets multiplateformes avec l'action GitHub, ou empaquetez-les comme extension MCP de bureau.
• Connaissances structurées sans nouveau langage de requête — Inspectez le frontmatter en NDJSON avec lore meta, interrogez-le avec jq et validez les Open Knowledge Format (OKF) de Google et les compétences d'agent près du chemin d'écriture.
• Politique et traitement extensibles — Les plugins peuvent ajouter validation, autorisations, middleware de lecture/écriture, métadonnées et traitement post-commit tout en préservant la même interface de système de fichiers.

Cas d'utilisation

• Dépôt d'apprentissage continu — stockez les sessions et les apprentissages dans un serveur partagé unique. Ajoutez des métriques pour optimiser. Permettez aux agents de partager leurs apprentissages entre eux tout en maintenant l'isolation des utilisateurs.
• Dépôt d'artefacts d'équipe — partagez des documents Markdown, HTML, JSON, Excel, etc. que vous avez créés tout en maintenant les contrôles d'accès. Beaucoup plus naturel que git, plus natif pour les agents que Confluence/Notion.
• Documentation pour les agents de codage — Placez la documentation API interne, les runbooks, le contexte produit et les notes d'architecture derrière une interface familière et interrogeable.
• Une mémoire vivante partagée pour des équipes d'agents — Donnez aux agents des docsets séparés ou partagés afin qu'ils puissent publier des résultats, se passer le travail et accumuler un contexte durable entre les sessions.
• Site de documentation public — ajoutez n'importe quels fichiers à votre docset public, activez l'accès public et ils seront montrés à tout agent qui tombe sur votre site. Améliore l'AEO/GEO sans avoir à modifier vos documents existants.
• Partage de compétences — Publiez des compétences d'agent dans des collections partagées afin que chaque agent autorisé puisse découvrir et utiliser les mêmes procédures gouvernées.
• Dépôt de plugins d'agents — Épinglez les versions des dépôts Agent Plugins depuis GitHub et servez-les aux agents de votre équipe. Les compétences empaquetées dans le standard ouvert restent à jour automatiquement.
• Contribution de connaissances gouvernée — Laissez les contributeurs publier dans des boîtes de réception tout en réservant les chemins sensibles aux approbateurs et en empêchant les écrasements accidentels.
• Revue à distance des artefacts d'agents — Exposez les rapports, journaux, captures d'écran et fichiers générés via le navigateur ou SSH sans créer de visualiseur d'artefacts personnalisé ni donner accès à la machine de l'agent.
• Espaces de travail spécifiques à l'identité — Montez un espace personnel pour chaque agent plus des connaissances d'équipe partagées, le tout via un seul serveur et un seul modèle d'autorisation.
• Connaissances portables pour clients ou projets — Livrez un exécutable versionné avec les documents pertinents intégrés, ou distribuez les mêmes connaissances comme extension de bureau MCPB.
• Catalogues de connaissances validés — Appliquez les conventions de frontmatter et de paquets, inspectez les métadonnées à moindre coût et arrêtez les connaissances malformées à l'admission.

Comment cela fonctionne

OpenLore est construit sur Wish pour le transport SSH. Une connexion est entièrement traitée contre un système de fichiers virtuel :

1. Authentifier — connectez-vous sans clé ou résolvez une clé SSH, un certificat, une clé d'accès ou une connexion OAuth en une identité.
2. Composer une vue — montez uniquement les docsets et chemins accordés à cette identité.
3. Explorer — exécutez des commandes shell implémentées comme fonctions Go pures sur cette vue, ou utilisez l'outil MCP shell équivalent.
4. Contribuer en toute sécurité — si l'écriture est activée, autorisez et validez un changement de fichier entier avant de le commettre atomiquement ou de le router pour approbation.

Les clients OAuth utilisent des identités déléguées, donc la provenance durable des écritures distingue le travail direct par adil du travail effectué en tant que adil/claude@claude.ai. Les délégués ne peuvent hériter de plus d'autorité que leur mandant et peuvent être restreints par docset et listes de refus de capacités. Les clients CIMD peuvent en outre s'authentifier avec des métadonnées hébergées par le fournisseur et private_key_jwt ; voir Clients OAuth authentifiés.

Le shell normal ne peut pas invoquer bash, exec, curl ni des processus hôtes arbitraires. La documentation intégrée est toujours en lecture seule. Les identités explicitement fiables peuvent recevoir un traitement asynchrone étroitement limité via la capacité spawn.

Écriture gouvernée

OpenLore est en lecture seule par défaut. Les déploiements avec écriture maintiennent un chemin d'écriture unique et contrôlé par politique pour les redirections, l'ajout, tee, patch, sed -i, les déplacements de fichiers, la publication et les tâches externes approuvées.

echo "# Research" | publish backend findings.md
cat change.diff | patch /backend/api.md
sed -i 's/old/new/g' /backend/runbook.md

Les écritures sont des échanges atomiques d'objets entiers. La protection par comparaison-et-échange rejette les modifications périmées par défaut, les autorisations de docset contraignent la cible, et certains chemins peuvent produire des ensembles de modifications révisables sous /requests au lieu de committer directement.

Consultez Écriture et publication pour la configuration côté utilisateur et Internes du système d'écriture pour le modèle d'implémentation.

Installation

Installer avec Go

Nécessite Go 1.26 ou ultérieur :

go install github.com/aakarim/go-openlore/cmd/openlore@latest

Compiler depuis la source

git clone https://github.com/aakarim/go-openlore.git
cd go-openlore
go build -o openlore ./cmd/openlore

Intégrer des documents dans un binaire

Placez la documentation dans assets/lore/ et compilez. Le binaire résultant contient les documents et les sert en lecture seule sur /docs lorsqu'il est exécuté sans argument de répertoire :

go build -o my-docs ./cmd/openlore

Compiler avec l'action GitHub

Produisez des binaires multiplateformes avec vos documents intégrés :

- uses: aakarim/openlore@v1
  with:
    docs-dir: ./docs
    config: ./openlore.yml

Consultez Façons d'utiliser OpenLore pour MCP stdio, l'empaquetage de bureau MCPB, SSHFS et l'utilisation de la bibliothèque Go.

Créer un déploiement personnalisé

Utilisez la compétence setup fournie pour créer <team>-lore, un petit dépôt appartenant au client contenant openlore.yml, un Containerfile mince épinglé à une version officielle d'OpenLore, et des artefacts de déploiement. Il construit un serveur local fonctionnel et vérifie HTTP, MCP, SSH authentifié, les écritures et la persistance avant le déploiement :

ssh openlore.sh setup | amp

Le dépôt généré conserve la politique lore.json initiale et les fichiers visibles SSH sous .local/ ignoré par git. Le premier déploiement initialise un volume persistant vide à partir de cet état. Le openlore.yml racine reste l'autorité Git/IaC et est déployé séparément vers /var/lib/openlore/config/openlore.yml ; il n'est pas intégré dans l'image. Les modifications ultérieures de lore.json et du système de fichiers sur le serveur sont faisant autorité et ne sont jamais écrasées par les mises à jour d'image.

Des commandes d'instructions supplémentaires prennent en charge le cycle de vie complet :

• onboarding ajoute localement les identités, rôles, espaces personnels et dossiers initiaux ;
• deploy sélectionne Fly.io, Railway, AWS, Google Cloud, Azure, DigitalOcean ou un déploiement personnalisé et vérifie un contrat de persistance/réseau partagé ;
• upgrade prépare uniquement le changement de version d'image de base épinglée afin que la CD existante puisse le déployer.

Les déploiements de fournisseurs exigent HTTPS/MCP, SSH OpenLore authentifié, un accès shell administratif et un volume /var/lib/openlore persistant. Lorsque le fournisseur le prend en charge, le déploiement configure le port public 22 pour transférer vers le port OpenLore 2222. Sinon, il signale le port attribué et recommande un système de transfert TCP externe.

Le conteneur publié contient uniquement OpenLore. Il ne contient délibérément aucune politique d'intégration ni configuration de serveur. Avant le démarrage du service, le déploiement doit placer openlore.yml et lore.json dans le répertoire de configuration persistant et exécuter :

./out --config /var/lib/openlore/config/openlore.yml

Cela maintient la configuration déployable indépendamment : un déploiement simple peut copier openlore.yml sur le volume, tandis que Kubernetes peut projeter le même fichier depuis une ConfigMap. Utilisez la compétence deploy pour Fly.io, Railway, AWS, Google Cloud, Azure, DigitalOcean ou une infrastructure personnalisée. Les fichiers Railpack et Fly du dépôt fournissent le câblage d'image, de volume persistant et de port ; ils ne préchargent ni ne modifient la configuration au démarrage du processus.

Railway attribue à son proxy TCP SSH un nom d'hôte et un port publics. Le port SSH standard 22 nécessite un équilibreur de charge TCP brut externe. Fly.io peut mapper le port public 22 vers le port interne 2222 d'OpenLore avec une adresse dédiée. Le SSH brut n'a pas de nom d'hôte ni de routage SNI, donc un seul écouteur ne peut pas router plusieurs domaines sur le port 22.

Le flux de travail de conteneur publie latest depuis main ; les versions publient également VERSION, vVERSION, les balises d'image majeures et mineures.

Téléversements HTTP vers la boîte de réception

Configurez un docset inbox et un rôle avec son autorisation publish, puis créez une identifiant pour une identité existante (la configuration du serveur doit nommer auth_file afin que la CLI puisse la valider) :

openlore inbox token create --identity alice --label webhook --config openlore.yml
curl -H 'Authorization: Bearer olin_ID_SECRET' -H 'Content-Type: text/markdown' \
  --data-binary @note.md 'https://docs.example.com/inbox/docs?name=note.md'

POST /inbox/{docset} accepte les identifiants porteur ou un HMAC de corps exact utilisant X-OpenLore-Token-Id et X-OpenLore-Signature. Les jetons d'accès OAuth sont utilisés uniquement pour POST/GET /inbox/tokens et DELETE /inbox/tokens/{id} ; les identifiants de boîte de réception sont séparés et révocables. Consultez Configuration et identité.

Documentation

Guide	Contenu
Façons d'utiliser OpenLore	SSH, MCP, web, SSHFS, binaires embarqués, GitHub Action, MCPB et utilisation en bibliothèque
Référence des commandes	Référence complète du shell, de l'introspection, de la publication, de la syntaxe, des commandes CLI et des drapeaux
Configuration et identité	openlore.yml, authentification, rôles, docsets, alias, répertoires personnels et vérification de l'hôte
Fédération d'identité de charge de travail	Authentifier les CI et les agents avec des jetons d'identité externes à courte durée de vie
Écriture et publication	Modes d'écriture, boîtes de réception, gestion des conflits, approbations et tâches
Plugins et formats de connaissances	Installation de plugins, interfaces, validation OKF, lore validate et lore meta
Internes du système d'écriture	Superposition du système de fichiers, couture d'écriture, ensembles de modifications, hooks et tâches asynchrones
Évaluation de la sécurité	Modèle de menace et propriétés de sécurité

Sécurité

• Les commandes s'exécutent dans un interpréteur pure-Go, pas via os/exec.
• Le système de fichiers virtuel nettoie les chemins et applique les limites des docsets.
• Les modèles de fichiers autorisés et les répertoires ignorés gardent les secrets hors de la vue.
• Le contrôle d'accès basé sur les rôles (RBAC) régit les lectures, la publication, les écritures, les approbations et les capacités de confiance.
• Le point de terminaison web peut publier la clé d'hôte SSH via TLS pour éviter une confiance aveugle lors de la première utilisation ; les certificats d'utilisateur et d'hôte SSH sont également pris en charge.

Voir SECURITY.md pour l'évaluation complète de la sécurité.

Licence

MIT — Adil Karim

OpenLore regroupe des composants open source tiers. Leurs licences et avis requis sont listés dans assets/legal/THIRD_PARTY_NOTICES.md, avec les textes complets des licences dans assets/legal/licenses/. Ceux-ci sont intégrés dans le binaire et servis par le service en cours d'exécution à /legal.