OpenLore

Richte OpenLore auf einen Ordner mit Markdown-Dateien aus, und jeder Agent in deinem Team liest dieselben Dateien – egal ob Claude Code, Codex, Cursor oder ein CI-Job. Agenten nutzen die Werkzeuge, die sie bereits kennen, wie cat, grep und find. Du entscheidest, wer was sehen und ändern kann.

_{Gehosteter Server mit einem Klick. Siehe OpenLore auf Render bereitstellen.}

Schnellstart

Installiere und stelle einen Ordner bereit:

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

SSH läuft auf Port 2222. Die Webansicht und MCP teilen sich Port 8080. Der Inhalt von ./docs erscheint unter /.

Verbinde einen Agenten:

# 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' /"

Sag deinen Agenten, wann sie es verwenden sollen:

ssh -p 2222 localhost agents >> AGENTS.md

Oder lass deinen Agenten die gesamte Einrichtung übernehmen:

ssh openlore.sh teach | claude

Kein Homebrew? Siehe den Schnellstart für Linux und Windows.

Warum nicht einfach Markdown im Repository behalten?

Für einen Agenten in einem Repository: tu das.

OpenLore ist für den Fall gedacht, dass mehrere Agenten, Repositories oder Personen dasselbe Wissen benötigen und du festlegen musst, wer was lesen, schreiben oder veröffentlichen darf. Aktualisiere eine Datei einmal, und jeder Agent sieht beim nächsten Lesen die neue Version.

Es gibt keine Vektordatenbank, keine Ingestions-Pipeline und kein SDK. Dein Wissen bleibt gewöhnliches Markdown.

Anleitungen

• Was ist OpenLore
• Claude Code
• Codex
• Cursor
• OpenCode
• Beliebiger Agent über SSH
• Einen Agenten in einen Posteingang veröffentlichen lassen
• Auf Render bereitstellen
• Alle Dokumentationen

Funktionen

• Agenten-native Abfrage – Agenten nutzen die Shell-Werkzeuge und Kompositionsmuster, die sie bereits verstehen, statt eine eigene Abfrage-API zu lernen.
• Eine Wissensoberfläche, mehrere Transporte – Stelle dasselbe virtuelle Dateisystem über SSH, SFTP/SSHFS (einschließlich direktem VS-Code-Durchsuchen und -Bearbeiten), MCP und eine benutzerfreundliche Webansicht bereit.
• Lebendiges, verwaltetes Wissen – Halte Inhalte schreibgeschützt, erlaube eingeschränktes Veröffentlichen oder aktiviere vollständige Schreibrechte pro Dokumentsatz. Schreibvorgänge sind atomar, konfliktbewusst und werden vor dem Commit validiert.
• Identitätsbezogene Ansichten – Gib jeder Person oder jedem Agenten nur die Dokumentsätze, die sie benötigt, mit rollenbasierten ro-, publish- und rw-Berechtigungen, Pfad-Aliasen und privaten Home-Verzeichnissen.
• Von Natur aus sicher – Die Shell ist ein In-Memory-Go-Interpreter, keine echte Betriebssystem-Shell. Es gibt keinen Shell-Escape, keine Ausführung beliebiger Prozesse und keinen Zugriff auf das Netzwerk in einer normalen Sitzung.
• Portable Wissenspakete – Bette Dokumente in eine eigenständige Binärdatei ein, erstelle plattformübergreifende Pakete mit der GitHub Action oder verpacke sie als Desktop-MCP-Erweiterung.
• Strukturiertes Wissen ohne neue Abfragesprache – Untersuche Frontmatter als NDJSON mit lore meta, frage es mit jq ab und validiere Googles Open Knowledge Format (OKF)-Pakete und Agent Skills nahe am Schreibpfad.
• Erweiterbare Richtlinien und Verarbeitung – Plugins können Validierung, Berechtigungen, Lese-/Schreib-Middleware, Metadaten und Verarbeitung nach dem Commit hinzufügen, während dieselbe Dateisystemschnittstelle erhalten bleibt.

Anwendungsfälle

• Continuous-Learning-Repository – Speichere Sitzungen und Erkenntnisse in einem gemeinsamen Server. Füge Metriken hinzu, um zu optimieren. Erlaube Agenten, Erkenntnisse untereinander zu teilen, während die Benutzerisolation erhalten bleibt.
• Team-Artefakt-Repository – Teile Markdown-, HTML-, JSON-, Excel- und andere Dokumente, die du erstellt hast, mit Zugriffskontrollen. Viel natürlicher als Git, agenten-nativer als Confluence/Notion.
• Dokumentation für Codierungsagenten – Lege interne API-Dokumente, Runbooks, Produktkontext und Architekturnotizen hinter einer vertrauten, durchsuchbaren Oberfläche ab.
• Ein gemeinsames lebendiges Gedächtnis für Agententeams – Gib Agenten getrennte oder gemeinsame Dokumentsätze, damit sie Erkenntnisse veröffentlichen, Arbeiten übergeben und dauerhaften Kontext über Sitzungen hinweg aufbauen können.
• Öffentliche Dokumentationsseite – Füge beliebige Dateien zu deinem öffentlichen Dokumentsatz hinzu, aktiviere den öffentlichen Zugriff, und sie werden jedem Agenten angezeigt, der auf deine Seite stößt. Verbessert AEO/GEO, ohne deine bestehende Dokumentation zu bearbeiten.
• Skills-Sharing – Veröffentliche Agent Skills in gemeinsamen Sammlungen, damit jeder autorisierte Agent dieselben verwalteten Verfahren entdecken und nutzen kann.
• Agent-Plugins-Repository – Pinne Agent Plugins-Repositories von GitHub per Version fest und stelle sie den Agenten deines Teams bereit. Skills, die im offenen Standard verpackt sind, bleiben automatisch aktuell.
• Verwalteter Wissensbeitrag – Erlaube Mitwirkenden, in Posteingänge zu veröffentlichen, während bestehende Dokumente für Maintainer reserviert bleiben und versehentliche Überschreibungen verhindert werden.
• Artefakt-Repository – Speichere und stelle Berichte, Logs, Screenshots und generierte Dateien über den Browser oder SSH bereit, ohne einen eigenen Artefakt-Viewer zu bauen oder Zugriff auf die Maschine des Agenten zu gewähren.
• Identitätsspezifische Arbeitsbereiche – Mounte ein privates Home-Verzeichnis für jeden Agenten plus gemeinsames Teamwissen, alles über einen Server und ein Autorisierungsmodell.
• Portables Kunden- oder Projektwissen – Liefere eine versionierte ausführbare Datei mit eingebetteten relevanten Dokumenten aus oder verteile dasselbe Wissen als MCPB-Desktop-Erweiterung.
• Validierte Wissenskataloge – Erzwinge Frontmatter- und Bundle-Konventionen, untersuche Metadaten kostengünstig und stoppe fehlerhaftes Wissen bereits bei der Aufnahme.

So funktioniert es

OpenLore basiert auf Wish für den SSH-Transport. Eine Verbindung wird vollständig gegen ein virtuelles Dateisystem verarbeitet:

1. Authentifizieren – Verbinde dich schlüssellos oder löse einen SSH-Schlüssel, ein Zertifikat, einen Passkey oder einen OAuth-Login zu einer Identität auf.
2. Eine Ansicht zusammenstellen – Mounte nur die Dokumentsätze und Pfade, die dieser Identität gewährt wurden.
3. Erkunden – Führe Shell-Befehle aus, die als reine Go-Funktionen über diese Ansicht implementiert sind, oder verwende das entsprechende MCP-shell-Werkzeug.
4. Sicher beitragen – Wenn Schreiben aktiviert ist, autorisiere und validiere eine Änderung der gesamten Datei, bevor du sie atomar committest.

OAuth-Clients verwenden delegierte Identitäten, sodass eine dauerhafte Schreibherkunft direkte Arbeit von adil von Arbeit als adil/claude@claude.ai unterscheidet. Delegierte können nicht mehr Autorität erben als ihr Auftraggeber und können durch Dokumentsatz- und Fähigkeits-Deny-Listen eingeschränkt werden. CIMD-Clients können sich zusätzlich mit vom Anbieter gehosteten Metadaten und private_key_jwt authentifizieren; siehe Authentifizierte OAuth-Clients.

Die normale Shell kann bash, exec, curl oder beliebige Host-Prozesse nicht aufrufen. Eingebettete Dokumentation ist immer schreibgeschützt. Explizit vertrauenswürdigen Identitäten kann durch die spawn-Fähigkeit eine eng begrenzte asynchrone Verarbeitung gewährt werden.

Verwaltetes Schreiben

OpenLore ist standardmäßig schreibgeschützt. Bereitstellungen mit Schreibzugriff behalten einen einzigen, richtliniengesteuerten Schreibpfad für Weiterleitungen, Anhängen, tee, patch, sed -i, Dateiverschiebungen, Veröffentlichungen und vertrauenswürdige externe Jobs.

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

Schreibvorgänge sind atomare Austausche des gesamten Objekts. Compare-and-Swap-Schutz lehnt veraltete Bearbeitungen standardmäßig ab, Dokumentsatz-Berechtigungen begrenzen das Ziel, und Plugins können einen Schreibvorgang vor dem Commit validieren oder aufschieben.

Siehe Schreiben und Veröffentlichen für die benutzerseitige Einrichtung und Interna des Schreibsystems für das Implementierungsmodell.

Installation

Siehe den Schnellstart für Homebrew-, Linux- und Windows-Versionen und welche Installationen das Dashboard enthalten. Um OpenLore selbst zu bauen, siehe Aus dem Quellcode bauen.

Dokumente in eine Binärdatei einbetten

Lege Dokumentation in assets/lore/ ab und baue. Die resultierende Binärdatei enthält die Dokumente und stellt sie schreibgeschützt unter /docs bereit, wenn sie ohne Verzeichnisargument ausgeführt wird:

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

Mit der GitHub Action bauen

Erstelle plattformübergreifende Binärdateien mit eingebetteten Dokumenten:

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

Siehe Möglichkeiten zur Nutzung von OpenLore für direktes VS-Code-Bearbeiten, MCP stdio, MCPB-Desktop-Paketierung, SSHFS und Go-Bibliotheksnutzung.

Eine angepasste Bereitstellung erstellen

Verwende die gebündelte setup-Fähigkeit, um <team>-lore zu erstellen, ein kleines kundeneigenes Repository, das openlore.yml, ein schlankes Containerfile, das auf eine offizielle OpenLore-Version gepinnt ist, und Bereitstellungsartefakte enthält. Es baut einen funktionierenden lokalen Server und verifiziert HTTP, MCP, authentifiziertes SSH, Schreibvorgänge und Persistenz vor der Bereitstellung:

ssh openlore.sh setup | amp

Das generierte Repository behält die anfängliche lore.json-Richtlinie und SSH-sichtbare Dateien unter gitignoriertem .local/. Die erste Bereitstellung initialisiert ein leeres persistentes Volume aus diesem Zustand. Root-openlore.yml bleibt die Git/IaC-Autorität und wird separat zu /var/lib/openlore/config/openlore.yml bereitgestellt; es ist nicht in das Image eingebacken. Spätere lore.json- und Dateisystembearbeitungen auf dem Server sind maßgeblich und werden niemals durch Image-Updates überschrieben.

Zusätzliche Befehlsfähigkeiten unterstützen den gesamten Lebenszyklus:

• onboarding fügt lokal anfängliche Identitäten, Rollen, Homes und Ordner hinzu;
• deploy wählt Fly.io, Railway, AWS, Google Cloud, Azure, DigitalOcean oder eine benutzerdefinierte Bereitstellung und verifiziert einen gemeinsamen Persistenz-/Netzwerkvertrag;
• upgrade bereitet nur die Änderung der gepinnten Basis-Image-Version vor, damit bestehendes CD sie bereitstellen kann.

Anbieterbereitstellungen erfordern HTTPS/MCP, authentifiziertes OpenLore-SSH, administrativen Shell-Zugriff und ein persistentes /var/lib/openlore-Volume. Wo der Anbieter es unterstützt, konfiguriert die Bereitstellung den öffentlichen Port 22 so, dass er an OpenLore-Port 2222 weiterleitet. Andernfalls meldet sie den zugewiesenen Port und empfiehlt ein externes TCP-Weiterleitungssystem.

Das veröffentlichte Container-Image enthält nur OpenLore. Es enthält bewusst keine Onboarding-Richtlinie oder Serverkonfiguration. Bevor der Dienst startet, muss die Bereitstellung openlore.yml und lore.json in das persistente Konfigurationsverzeichnis legen und ausführen:

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

Dies hält die Konfiguration unabhängig bereitstellbar: Eine einfache Bereitstellung kann openlore.yml auf das Volume kopieren, während Kubernetes dieselbe Datei aus einem ConfigMap projizieren kann. Verwende die deploy-Fähigkeit für Fly.io, Railway, AWS, Google Cloud, Azure, DigitalOcean oder benutzerdefinierte Infrastruktur. Die Railpack- und Fly-Dateien des Repositories stellen das Image, das persistente Volume und die Port-Verdrahtung bereit; sie seeden oder mutieren die Konfiguration beim Prozessstart nicht.

Für einen schnellen gehosteten Server ohne angepasstes Repository verwende die Schaltfläche Auf Render bereitstellen. Im Gegensatz zu den Railpack- und Fly-Dateien schreibt ihr Startskript beim ersten Boot eine Starter-openlore.yml und lore.json auf eine leere Festplatte. Render stellt nur HTTPS, MCP und die Webansicht bereit; es hat keinen öffentlichen TCP-Eingang für OpenLore-SSH.

Railway weist seinem SSH-TCP-Proxy einen öffentlichen Hostnamen und Port zu. Standard-SSH-Port 22 erfordert einen externen Raw-TCP-Lastbalancer. Fly.io kann den öffentlichen Port 22 mit einer dedizierten Adresse auf OpenLores internen Port 2222 abbilden. Raw-SSH hat kein Hostname- oder SNI-Routing, daher kann ein Listener keine mehreren Domains auf Port 22 routen.

Der Container-Workflow veröffentlicht latest aus main; Releases veröffentlichen auch VERSION, vVERSION, Major- und Minor-Image-Tags.

Dokumentation

Dieselben Seiten, in denselben Gruppen, werden unter openlore.sh/docs veröffentlicht.

Einführung

Seite	Inhalt
Was ist OpenLore	Bereitstellen, verbinden, eingrenzen, verwalten und beobachten auf einer Seite
Changelog	Aktuelle Version, Versionshinweise, Kompatibilitätshinweise und versionierte Dokumentation

Start

Seite	Inhalt
Schnellstart	OpenLore installieren, einen Ordner bereitstellen und einen Agenten verbinden
Claude Code	Claude Code über MCP verbinden und festlegen, was es sehen darf
Codex	Codex über MCP verbinden
Cursor	Cursor über MCP verbinden
OpenCode	OpenCode über MCP verbinden
Beliebiger Agent über SSH	Einen Coding-Agenten oder CI-Job über SSH verbinden und ihm eine Identität geben

Konzepte

Wie OpenLore funktioniert: Docsets, Transports, Identität, Schreiben, Regeln und Beobachtung.

Seite	Inhalt
Docsets	Was ein Docset ist, warum der Zugriff darum organisiert ist und wie Verschachtelung, Berechtigungen, Aliase und Fail-Closed-Validierung funktionieren
Transports	Wie SSH, SFTP, MCP, die JSON-API und das Web ein gemeinsames Dateisystem nutzen, die MCP-Tools, Befehlsergebnisse, Sitzungen und Anweisungsbefehle
Authentifizierung	Authentifizierungsmodell, wie SSH-Schlüssel, Zertifikate, Passkeys, OAuth-Tokens und Inbox-Anmeldedaten zu einer Identität, Rollen, Docsets, Aliasen, Homes und Workload-Identitäts-Föderation auflösen
Schreiben und Veröffentlichen	Schreibmodi, Inboxen, Konfliktbehandlung, was ein erfolgreicher Schreibvorgang prüft und nicht prüft, und Jobs
Ordnerregeln	.lore/config.yaml- und lore.json-Regeln, Schichtung, Berechtigungen, Ablehnungsmeldungen und Wachstumsgrenzen
Plugins und Formate	Provider-Schnittstellen, Open-Knowledge-Format-Validierung, lore validate, lore meta und das Agent-Skills-Plugin
Dashboard und Metriken	Dashboard-Authentifizierung, Fakten versus Aktivität und der Dateibetrachter

Anleitungen

Aufgaben-Durchläufe.

Seite	Inhalt
Einsatzmöglichkeiten von OpenLore	SSH, MCP über HTTP und stdio, die Webansicht, SSHFS, eingebettete Binärdateien, die GitHub-Action, MCPB und Bibliotheksnutzung einrichten
Server konfigurieren	openlore.yml erstellen, Vorrang vor eingebetteter Konfiguration und Flags, Analyse und Debug-Protokollierung
Einem Agenten erlauben, in eine Inbox zu veröffentlichen	Beiträge von einem Agenten annehmen, ohne ihm zu erlauben, etwas anderes zu bearbeiten
Aus einem Editor durchsuchen und bearbeiten	Direkte VS-Code- und SFTP-Editor-Einrichtung ohne lokales Projekt-Spiegelbild
Headlong / shellm ausführen	OpenLore über SSH aus der shellm-Engine von headlong nutzen, einschließlich seiner Haushalts-Fähigkeit
Aus dem Quellcode bauen	Die Weboberfläche und die Binärdatei selbst bauen oder ohne die Weboberfläche bauen
OpenLore auf Render bereitstellen	Ein-Klick-Render-Bereitstellung, erste Passkey-Anmeldung, Upgrades und benutzerdefinierte Domains

Referenz

Nachschlagematerial: Befehle, Schlüssel, Endpunkte, Schnittstellen und Interna.

Seite	Inhalt
Befehlsreferenz	Vollständige Shell-, Introspektions-, Veröffentlichungs-, Syntax-, CLI-Befehls- und Flag-Referenz
openlore.yml-Referenz	Generierte Referenz für jeden Schlüssel, den openlore.yml akzeptiert
Regel-Standardbibliothek	Generierte Referenz für kompilierte Regelmitglieder und ihre Parameter
HTTP-Inbox-API	POST /inbox/{docset} mit Bearer- oder HMAC-Anmeldedaten und die Token-Endpunkte
OAuth-Clients	CIMD-Client-Identität, private_key_jwt, mTLS-Bestätigung und Signaturschlüssel-Rotation
Interna des Schreibsystems	Dateisystem-Schichtung, Schreibnaht, Zulassungs-Middleware und asynchrone Jobs
Dashboard bauen	Frontend-Build und Backend-only-Go-Builds
Sicherheitsbewertung	Bedrohungsmodell und Sicherheitseigenschaften

Sicherheit

• Befehle laufen in einem reinen Go-Interpreter, nicht über os/exec.
• Das virtuelle Dateisystem bereinigt Pfade und erzwingt Docset-Grenzen.
• Zulässige Dateimuster und ignorierte Verzeichnisse halten Geheimnisse aus der Ansicht fern.
• RBAC steuert Lesezugriffe, Veröffentlichung, Schreibvorgänge, Genehmigungen und vertrauenswürdige Fähigkeiten.
• Der Web-Endpunkt kann den SSH-Hostschlüssel über TLS veröffentlichen, um Blindvertrauen bei der ersten Nutzung zu vermeiden; SSH-Benutzer- und Host-Zertifikate werden ebenfalls unterstützt.

Siehe SECURITY.md für die vollständige Sicherheitsbewertung.

Lizenz

Apache-Lizenz 2.0 — Copyright © 2026 Adil Karim

OpenLore bündelt Open-Source-Komponenten von Drittanbietern. Deren Lizenzen und erforderliche Hinweise sind in assets/legal/THIRD_PARTY_NOTICES.md aufgeführt, mit vollständigen Lizenztexten in assets/legal/licenses/. Diese sind in der Binärdatei eingebettet und werden vom laufenden Dienst unter /legal bereitgestellt.