OpenLore

Pointez OpenLore vers un dossier de Markdown et chaque agent de votre équipe lit les mêmes fichiers, qu'il s'agisse de Claude Code, Codex, Cursor ou d'un travail CI. Les agents utilisent les outils qu'ils connaissent déjà, comme cat, grep et find. Vous décidez qui peut voir et modifier quoi.

_{Serveur hébergé en un clic. Voir Déployer OpenLore sur Render.}

Démarrage rapide

Installez et servez un dossier :

brew install --cask aakarim/tap/lore
openlore ./docs

SSH écoute sur le port 2222. La vue web et MCP partagent le port 8080. Le contenu de ./docs apparaît à /.

Connectez un agent :

# Claude Code
claude mcp add --transport http openlore http://localhost:8080/mcp

# Codex
codex mcp add openlore --url http://localhost:8080/mcp

# Anything with a shell
ssh -p 2222 localhost "grep -r 'retry' /"

Dites à vos agents quand l'utiliser :

ssh -p 2222 localhost agents >> AGENTS.md

Ou laissez votre agent faire toute la configuration :

ssh openlore.sh teach | claude

Pas sur Homebrew ? Voir le Démarrage rapide pour Linux et Windows.

Pourquoi ne pas simplement garder le Markdown dans votre dépôt ?

Pour un agent dans un dépôt, faites cela.

OpenLore est conçu pour quand plusieurs agents, dépôts ou personnes ont besoin des mêmes connaissances, et que vous devez définir qui peut lire, écrire ou publier quoi. Mettez à jour un fichier une fois et chaque agent voit la nouvelle version à sa prochaine lecture.

Il n'y a pas de base de données vectorielle, de pipeline d'ingestion ou de SDK. Vos connaissances restent en Markdown ordinaire.

Guides

• Qu'est-ce qu'OpenLore
• Claude Code
• Codex
• Cursor
• OpenCode
• N'importe quel agent via SSH
• Laisser un agent publier dans une boîte de réception
• Déployer sur Render
• Toute la documentation

Fonctionnalités

• Récupération native pour agents — Les agents utilisent les outils shell et les modèles de composition qu'ils comprennent 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 (y compris la navigation et l'édition directes dans VS Code), MCP, et une vue web conviviale.
• Connaissances vivantes et gouvernées — Gardez le contenu en lecture seule, autorisez la publication ciblée, ou activez les écritures complètes par ensemble de documents. Les écritures sont atomiques, conscientes des conflits et validées avant d'être engagées.
• Vues limitées par identité — Donnez à chaque personne ou agent uniquement les ensembles de documents dont il a besoin, avec des autorisations basées sur les rôles pour ro, publish et rw, des alias de chemins et des répertoires personnels privés.
• Sûr par conception — Le shell est un interpréteur Go en mémoire, pas un vrai shell de système d'exploitation. Il n'y a pas d'échappement shell, d'exécution de processus arbitraire ou 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 paquets 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é. 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 les docs API internes, les runbooks, le contexte produit et les notes d'architecture derrière une interface familière et consultable.
• Une mémoire vivante partagée pour les équipes d'agents — donnez aux agents des ensembles de documents séparés ou partagés pour qu'ils puissent publier des résultats, se passer le travail et accumuler un contexte durable entre les sessions.
• Site de documentation publique — ajoutez n'importe quels fichiers à votre ensemble de documents 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 docs existantes.
• Partage de compétences — publiez des compétences d'agent dans des collections partagées pour que chaque agent autorisé puisse découvrir et utiliser les mêmes procédures gouvernées.
• Dépôt de plugins d'agent — épinglez les dépôts Agent Plugins de GitHub par version 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 documents existants aux mainteneurs et en empêchant les écrasements accidentels.
• Dépôt d'artefacts — stockez et exposez des rapports, journaux, captures d'écran et fichiers générés via le navigateur ou SSH sans construire un visualiseur d'artefacts sur mesure 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, tout via un seul serveur et un seul modèle d'autorisation.
• Connaissances portables client ou projet — livrez un exécutable versionné avec les docs pertinentes intégrées, ou distribuez les mêmes connaissances comme extension de bureau MCPB.
• Catalogues de connaissances validés — imposez 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 ça 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 vers une identité.
2. Composer une vue — montez uniquement les ensembles de documents et les 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 équivalent shell.
4. Contribuer en toute sécurité — si l'écriture est activée, autorisez et validez un changement de fichier entier avant de l'engager atomiquement.

Les clients OAuth utilisent des identités déléguées, donc la provenance durable des écritures distingue le travail direct de adil du travail effectué comme adil/claude@claude.ai. Les délégués ne peuvent hériter de plus d'autorité que leur principal et peuvent être restreints par des listes de refus par ensemble de documents et par capacité. Les clients CIMD peuvent en plus 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 ou des processus hôtes arbitraires. La documentation intégrée est toujours en lecture seule. Les identités explicitement de confiance 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 gardent 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 travaux externes de confiance.

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 obsolètes par défaut, les autorisations d'ensemble de documents contraignent la cible, et les plugins peuvent valider ou différer une écriture avant qu'elle ne soit engagée.

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

Installation

Voir le Démarrage rapide pour les versions Homebrew, Linux et Windows, et quelles installations incluent le tableau de bord. Pour construire OpenLore vous-même, voir Construction à partir des sources.

Intégrer des documents dans un binaire

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

make dashboard-build   # optional: include the web UI
go build -o my-docs ./cmd/openlore

Construire 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

Voir Façons d'utiliser OpenLore pour l'édition directe dans VS Code, 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 incluse 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é garde la politique initiale lore.json et les fichiers visibles SSH sous .local/ gitignoré. Le premier déploiement initialise un volume persistant vide à partir de cet état. La racine openlore.yml reste l'autorité Git/IaC et est déployée séparément vers /var/lib/openlore/config/openlore.yml ; elle n'est pas intégrée dans l'image. Les modifications ultérieures de lore.json et du système de fichiers sur le serveur sont autoritatives 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 pour 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 persistant /var/lib/openlore. Là où le fournisseur le prend en charge, le déploiement configure le port public 22 pour rediriger vers le port OpenLore 2222. Sinon, il signale le port attribué et recommande un système de redirection TCP externe.

Le conteneur publié ne contient qu'OpenLore. Il ne contient délibérément aucune politique d'intégration ni configuration 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 rend la configuration indépendamment déployable : 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 l'image, le volume persistant et le câblage des ports ; ils ne seedent ni ne modifient la configuration au démarrage du processus.

Pour un serveur hébergé rapide sans dépôt personnalisé, utilisez le bouton Déployer sur Render. Contrairement aux fichiers Railpack et Fly, son script de démarrage écrit un openlore.yml et un lore.json de départ sur un disque vide au premier démarrage. Render sert HTTPS, MCP et la vue web uniquement ; il n'a pas d'entrée TCP publique pour SSH OpenLore.

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 routage par nom d'hôte ou SNI, donc un seul écouteur ne peut pas router plusieurs domaines sur le port 22.

Le flux de travail du conteneur publie latest depuis main ; les versions publient aussi VERSION, vVERSION, et les tags d'image majeurs et mineurs.

Documentation

Les mêmes pages, dans les mêmes groupes, sont publiées sur openlore.sh/docs.

Introduction

Page	Contenu
Qu'est-ce qu'OpenLore	Servir, connecter, limiter, gouverner et observer en une page
Journal des modifications	Version actuelle, notes de version, notes de compatibilité et documentation versionnée

Démarrage

Page	Contenu
Démarrage rapide	Installer OpenLore, servir un dossier et connecter un agent
Claude Code	Connecter Claude Code via MCP et limiter ce qu'il voit
Codex	Connecter Codex via MCP
Cursor	Connecter Cursor via MCP
OpenCode	Connecter OpenCode via MCP
N'importe quel agent via SSH	Connecter un agent de codage ou un travail CI via SSH et lui donner une identité

Concepts

Comment OpenLore fonctionne : docsets, transports, identité, écritures, règles et observation.

Page	Contenu
Docsets	Ce qu'est un docset, pourquoi l'accès est organisé autour d'eux, et comment fonctionnent l'imbrication, les autorisations, les alias et la validation en mode échec-fermé
Transports	Comment SSH, SFTP, MCP, l'API JSON et le web partagent un même système de fichiers, les outils MCP, les résultats de commandes, les sessions et les commandes d'instruction
Authentification	Posture d'authentification, comment les clés SSH, certificats, passkeys, jetons OAuth et identifiants de boîte de réception se résolvent en une identité, rôles, docsets, alias, répertoires personnels et fédération d'identité de charge de travail
Écriture et publication	Modes d'écriture, boîtes de réception, gestion des conflits, ce qu'une écriture réussie vérifie et ne vérifie pas, et travaux
Règles de dossier	Règles .lore/config.yaml et lore.json, superposition, permissions, messages de rejet et limites de croissance
Plugins et formats	Interfaces fournisseur, validation du format Open Knowledge, lore validate, lore meta et le plugin Agent Skills
Tableau de bord et métriques	Authentification du tableau de bord, faits par rapport à l'activité, et visionneuse de fichiers

Comment faire

Procédures pas à pas.

Page	Contenu
Façons d'utiliser OpenLore	Configurer SSH, MCP via HTTP et stdio, la vue web, SSHFS, les binaires embarqués, l'action GitHub, MCPB et l'utilisation de la bibliothèque
Configurer le serveur	Créer openlore.yml, priorité sur la configuration embarquée et les drapeaux, analytique et journalisation de débogage
Laisser un agent publier dans une boîte de réception	Accepter les contributions d'un agent sans lui permettre de modifier autre chose
Parcourir et modifier depuis un éditeur	Configuration directe de VS Code et de l'éditeur SFTP sans miroir de projet local
Exécuter headlong / shellm	Utiliser OpenLore via SSH depuis le moteur shellm de headlong, y compris sa compétence de maintenance
Compiler depuis les sources	Compiler l'interface web et le binaire vous-même, ou compiler sans l'interface web
Déployer OpenLore sur Render	Déploiement Render en un clic, première connexion par passkey, mises à niveau et domaines personnalisés

Référence

Matériel de consultation : commandes, clés, points de terminaison, interfaces et détails internes.

Page	Contenu
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
Référence openlore.yml	Référence générée pour chaque clé que openlore.yml accepte
Bibliothèque standard de règles	Référence générée pour les membres de règles compilés et leurs paramètres
API HTTP de boîte de réception	POST /inbox/{docset} avec identifiants bearer ou HMAC, et les points de terminaison de jetons
Clients OAuth	Identité client CIMD, private_key_jwt, corroboration mTLS et rotation des clés de signature
Détails internes du système d'écriture	Superposition du système de fichiers, couture d'écriture, middleware d'admission et travaux asynchrones
Compiler le tableau de bord	Compilation du frontend et compilations Go backend uniquement
É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 purement 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 RBAC contrôle les lectures, la publication, les écritures, les approbations et les capacités de confiance.
• Le point de terminaison web peut publier la clé hôte SSH via TLS pour éviter la 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

Licence Apache 2.0 — Copyright © 2026 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 embarqués dans le binaire et servis par le service en cours d'exécution à /legal.