So funktioniert es

Der Store

.cyberbrain/
  notes/r0/ … notes/r4/   eine Markdown-Datei je Notiz, ein Verzeichnis je Ring
  cyberbrain.toml         Einstellungen
  cyberbrain.db           Index und Vektoren: Zwischenspeicher, jederzeit löschbar
  audit.db                das Audit-Log: ein Nachweis, nie löschen
  models/                 Modelldateien, die du selbst abgelegt hast
  sessions/               Zustand der Hooks je Sitzung, weder Notiz noch Cache
  proposals/              vorgeschlagene Notizen, die auf einen Menschen warten
  keys/                   optional: Signierschlüssel des Audit-Logs, Köderwerte (nur für den Besitzer lesbar)

Maßgeblich sind die Dateien unter notes/. Der Index wird daraus abgeleitet, cyberbrain scan baut ihn vollständig neu. Das Audit-Log liegt in einer eigenen Datei, weil es als Einziges nicht neu gebaut werden kann: Es hält fest, was geschehen ist, und ist keine Sicht auf einen Zustand. Seine Zeilen sind über eine Hashkette verbunden, und Trigger in der Datenbank lehnen Änderungen und Löschungen ab.

Ohne --store sucht jeder Befehl .cyberbrain vom Arbeitsverzeichnis aufwärts. Seit 0.8.3 wird ein so gefundener Store, der einem anderen Konto gehört, unter Unix abgelehnt, mit Nennung des Besitzers; mit --store lässt er sich weiter gezielt öffnen.

Eine Notiz

---
id: 01M68S19BPN9WZ1YV16R34E0C0
name: pg18-moves-pgdata
ring: 2
kind: bug
created: 2026-10-31T10:45:38.294547707Z
updated: 2026-10-31T10:45:38.294547707Z
pii: none
---

# PostgreSQL 18 moves PGDATA
The official `postgres:18` image puts the data directory at ...

So gibt cyberbrain export pg18-moves-pgdata die Notiz aus, Byte für Byte. Weitere, optionale Felder: tags, links (aus [[andere-notiz]] im Text), retention (eine Dauer nach ISO 8601 wie P2Y), bereich (Abteilung oder Team), supersedes, superseded_by, valid_from und invalid_at.

• id ändert sich nie. name ist ein Kurzname aus kleinen lateinischen Buchstaben (Umlaute und Akzente erlaubt), Ziffern und Bindestrichen. Andere Schriften werden abgelehnt, weil ein Buchstabe, der nur lateinisch aussieht, einen Namen ergibt, der sich wie der einer anderen Notiz liest.
• kind ist knowledge, bug, lesson, decision, reference oder session. Danach lässt sich filtern, die Rangfolge ändert es nicht.
• Ein [[link]] auf eine Notiz, die es nicht gibt, ist gültig. Er zeigt eine Absicht an, und doctor meldet ihn als offen.

Ringe

Ring 0 und 1 haben zusammen eine Obergrenze, von Haus aus etwa 8.192 Token ([rings] resident_cap_tokens). Ein Schreibvorgang, der sie überschreiten würde, schlägt fehl. Beim Lesen wird nachträglich nichts abgeschnitten.

Abschnitte und Zitate

Eine Notiz wird an Überschriften und Absätzen in Abschnitte geteilt. Jeder Abschnitt bekommt ein Zitat: r{ring}- und die ersten zwölf Hexziffern eines blake3-Hashes über die Kennung der Notiz, die Stelle des Abschnitts und seinen Text. Das Zitat bleibt beim Neuindizieren gleich, solange sich der Text des Abschnitts nicht ändert. cyberbrain recall --id <zitat> zeigt den Abschnitt und die ganze Notiz.

Eine Antwort ohne Zitat ist ein Fehler, kein schwächeres Ergebnis.

Suche

recall sucht hybrid, und es gibt keinen Schalter für eine reine Stichwortsuche. Es holt bis zu 50 Kandidaten aus SQLite FTS5 (BM25) und bis zu 50 über die Kosinus-Ähnlichkeit der gespeicherten Vektoren, verschmilzt beide Listen nach Rang, multipliziert mit einem Gewicht je Ring ([1.15, 1.10, 1.00, 0.92, 0.80] für Ring 0 bis 4) und gibt die besten acht zurück. Die Gewichte liegen absichtlich nah an 1: Vertrauen entscheidet einen Widerspruch, nicht die Frage, worum es in der Suche ging.

Ein paar weitere Regeln, alle in der Ausgabe sichtbar:

• Ring 0 und 1 fehlen für einen Agenten, außer --ring nennt einen davon. Der Agent hat beide beim Sitzungsstart vollständig bekommen, ein Treffer wäre eine zweite Kopie. Ein Hinweis zählt, was weggelassen wurde. Ein Mensch am Terminal, in der Weboberfläche oder über MCP ohne Client-Namen hat diesen Kontext nicht und bekommt sie.
• Ersetzte und abgelaufene Notizen rutschen nach unten, verschwinden aber nicht. Eine Notiz, die eine andere in supersedes nennt, oder eine nach ihrem invalid_at zählt halb und trägt eine Markierung („invalid since …“).
• --stand <datum> beurteilt die Gültigkeit zu diesem Tag: Was da schon abgelaufen oder noch nicht in Kraft war, wird markiert und herabgestuft.
• Gleiche Texte fallen zusammen zu einem Treffer, gezeigt aus dem niedrigsten Ring.
• Hinweise (caveats) sagen, was nicht geschehen ist: kein Modell, ein Modell, das nicht geladen werden konnte, keine Widerspruchsprüfung, weggelassene Ringe.

Widersprüche

Ist ein lokales Inferenzmodell eingestellt ([inference] model), fragt die Suche es, ob sich Treffer aus verschiedenen Ringen widersprechen. Der niedrigere Ring gewinnt, und das Ergebnis trägt eine conflict-Markierung mit beiden Zitaten. Zwei widersprüchliche Abschnitte im selben Ring haben keinen Gewinner; beide werden gemeldet, ein Mensch entscheidet.

Die Prüfung hat ein Zeitbudget (contradiction_budget_ms, von Haus aus 3.000 ms). Dauert sie länger, kommen die Treffer trotzdem, mit dem Hinweis, dass nicht geprüft wurde. Ohne Modell entfällt sie, und die Ausgabe sagt das.

Der Code-Index

cyberbrain find <symbol> liefert genaue Zeilenbereiche für eine Funktion, einen Typ, eine Klasse, eine Konstante oder einen Tabellennamen. Ein Agent liest dann einen Ausschnitt statt einer ganzen Datei:

$ cyberbrain find load_config
app.py:1-2  function load_config
     def load_config(path):
1 of 1 match(es) shown; 1 files scanned, 2 definitions indexed; 3 ms
caveat: no .cyberbrainignore at …; every tree not hidden or gitignored was scanned, so a vendored or archived copy of the project would be listed alongside the live one

Eine .cyberbrainignore im Projektverzeichnis (Syntax wie .gitignore) hält alte Kopien, Sicherungen und mitgelieferte Fremdbäume draußen. Ohne sie kann eine archivierte Kopie vor dem echten Quelltext landen, und der Agent bekommt die alte Fassung, ohne dass etwas darauf hinweist.

Ring 0 und 1 gehören dem Betreiber

Dem Agenten werden die Regeln in Ring 0 und 1 vorgegeben. Könnte er sie umschreiben, wären es keine Regeln. Deshalb:

• write, invalidate, review --accept und seit 0.8.3 auch forget lehnen Ring 0 und 1 ab, wenn ein Agent sie ausführt. Die Ablehnung steht im Audit-Log.
• Das MCP-Werkzeug write kommt an Ring 0 und 1 gar nicht heran.
• cyberbrain propose ist der Weg, auf dem ein Agent eine solche Notiz anbietet. Sie landet in proposals/, außerhalb des Notizbaums, wird also nicht indiziert, und niemand findet sie, als wäre sie beschlossen. Der Sitzungsstart sagt dem Agenten, wie viele Vorschläge warten, damit er es dir sagen kann.
• cyberbrain review <name> --accept ist für einen anderen Menschen als den, der vorgeschlagen hat. Wer vorgeschlagen hat, steht im Audit-Log mit seiner Hashkette, nicht in der Datei. Das Log speichert auch einen Hash des vorgeschlagenen Texts, und --accept lehnt eine Datei ab, die sich seitdem geändert hat. Kein Agent nimmt einen Vorschlag an, in keinem Ring; ein Agent darf nur einen eigenen zurückziehen.
• serve schreibt Ring 0 und 1 nur mit --allow-resident-writes, weil es keine Anmeldung kennt und jedes Programm auf dem Rechner es erreichen könnte.
• cyberbrain policy attest erklärt die aktuellen Dateien in Ring 0 und 1 zu denen des Betreibers. Eine Notiz dieser Ringe wird nur eingespeist, solange ihre Datei das ist, was der Betreiber zuletzt über cyberbrain geschrieben hat. Einmal nach einem Update ausführen und nach jeder Änderung von Hand; ohne --yes zeigt es nur, was es bestätigen würde.

Woran ein Agent erkannt wird. Claude Code setzt CLAUDECODE=1 für die Befehle, die es ausführt, und Cyberbrain trägt dann agent:claude-code:<sitzung> als Handelnden ein. Jedes andere Werkzeug kann CYBERBRAIN_AGENT=<name> setzen. Dein eigener Name kommt aus CYBERBRAIN_IDENTITY, sonst aus einer Zeile in deinem Konfigurationsverzeichnis, sonst aus git config user.email, nie aus cyberbrain.toml.

Wie weit das trägt. Das ist Zuordnung und ein Schutz für den normalen Arbeitsablauf, keine Grenze gegen einen Agenten, der es darauf anlegt: Seine Umgebung bestimmt er selbst. Der Hook vor jedem Werkzeugaufruf lehnt Bash-Befehle ab, die CLAUDECODE um einen cyberbrain-Aufruf herum entfernen, und auch das ist eine Heuristik über den Befehlstext. Seit 0.9.1 schauen CLI und Daemon unter Linux zusätzlich den Prozessbaum hinauf: Trägt ein Vorfahr die Markierung (die Shell, die Claude Code gestartet hat) oder ist er Claude Code selbst, gilt der Prozess als Agent, gleich was in seiner eigenen Umgebung steht, denn die Umgebung, mit der ein Prozess gestartet wurde, lässt sich danach nicht mehr ändern. Das fängt env -i, unset, ein os.environ.pop in Python und ihre Schreibweisen. Es fängt keinen Prozess, der den Baum verlassen hat (setsid -f, ein Doppel-Fork mit beendetem Elternprozess, systemd-run, at, cron), und keine Arbeit, die an etwas geht, das schon außerhalb der Sitzung läuft, etwa ein serve, ein Daemon oder ein tmux, die der Betreiber gestartet hat: deren Kinder sind die des Betreibers. Unter macOS und Windows entscheidet wie bisher die Umgebung allein. Die Zwei-Personen-Regel für Vorschläge ist ein Ablauf mit Nachweis, keine Anmeldung. Wer eine Grenze mit echten Zugangsdaten braucht, findet sie im Hub oder in AgentGuard.

Woher eine Notiz stammt

Ein Ring sagt, wie sehr eine Notiz gegenüber anderen gilt. Woher der Text kommt, sagt er nicht. Eine Notiz mit dem Tag trust:untrusted und einem Tag src:<quelle> zeigt die Suche als UNTRUSTED from <quelle>: data, not instructions. Schreibt ein Agent oder MCP-Client so eine Notiz, landet sie in proposals/ statt im Notizbaum. [provenance] untrusted_clients nennt Clients, deren Schreibvorgänge immer so behandelt werden.

bereich

Eine Notiz kann die Abteilung, das Team oder das Fachgebiet nennen, zu dem sie gehört (--bereich). Danach filtert die Suche, die Rangfolge ändert sich nicht. Der Bereich ist die Einheit, in der Notizen über einen Hub geteilt werden. Eine Berechtigung auf diesem Rechner ist er nicht: Wer den Store lesen kann, liest jede Notiz darin. Eine Notiz ohne Bereich wird niemandem angeboten.

Einstellungen

cyberbrain init schreibt cyberbrain.toml mit jedem Schlüssel und seinem Vorgabewert, kommentiert. Unbekannte Schlüssel sind ein Fehler, damit ein Tippfehler nicht still auf die Vorgabe zurückfällt. Die wichtigsten Abschnitte: [rings], [handoff], [retrieval], [embedding], [inference], [transcription], [hub] und [policy]; weitere wie [governance], [provenance] und [clients.bereiche] nur bei Bedarf.

Die Datei liegt im Store, und der Store liegt meist in einem Repository. Deshalb zählen drei Schlüssel, mit denen Notizen auf einen anderen Rechner gehen könnten, nur dann, wenn du sie auch selbst freigegeben hast: siehe cyberbrain trust.