Systemnotizen · Stand 30.08.2026
Exakte Provenienz verbindet Journal, kuratiertes Wissen und indexierte Dokumentversionen jetzt ohne Graph. Eine private mobile Leseschicht und ein eng begrenzter Review-Launcher verkürzen zwei Medienbrüche. Beide Hilfen bleiben abgeleitet: weder Browser noch Gedächtnis werden zur technischen Autorität.
Seit 18.08.2026
CodexJournal kann eine bewusste Wissenspromotion append-only an ihre Quellereignisse binden. Akasha löst diese technische Referenz exakt auf; devMCP liefert Dokument-, Hash- und Manifestprovenienz mit sichtbarer Drift. Hinzu kommt ein revisionsgebundener Review-Intent, dessen Ausführung auf einem lokalen, read-only Companion bleibt.
Eine produktive Promotion wurde bereits in beide Richtungen exakt aufgelöst. Repository-Dokumentation wird nach erfolgreichen Indexläufen in eine private, mobil lesbare Arbeitskopie gespiegelt. Der Review-Launcher ist ausgerollt und sein Sicherheitsprofil real geprüft; eine regelmäßige Review-Nutzung ist noch nicht belegt.
Exakte Referenzen lösen heute das konkrete Navigationsproblem, für das ein Graph sonst zu früh zusätzliche Semantik und Betrieb einführen würde. Die mobile Leseschicht senkt Reibung, erzeugt aber Sync-, Konflikt- und Backupaufwand. Der Review-Launcher ist nur dann ein Gewinn, wenn seine enge Vertrauensgrenze kleiner bleibt als der ersetzte manuelle Kontextwechsel.
Das System
Der letzte Übergang ist absichtlich manuell. Ein abgeschlossenes Journal-Ereignis wird nicht automatisch zu dauerhaftem Wissen.
Suche beschleunigt das Finden. Sie autorisiert keine Aussage und ersetzt weder Code noch DDL oder Laufzeitbeleg.
Das Journal speichert kleine, typisierte Nachweise statt eines vollständigen Transkripts der Arbeit.
Ein leises Gedächtnis mit Lücken ist nützlicher als eine große Sammlung unbestätigter Zusammenfassungen.
Kernwerkzeuge
Alle drei Werkzeuge dieses Stands laufen im beschriebenen Entwicklungsworkflow. Keines davon ist als allgemeine Plattform gedacht.
Operative Provenienz
Hält fest, was eine Arbeitseinheit erreichen soll, welche Entscheidungen gefallen sind und woran ihr Ergebnis geprüft wurde.
Git zeigt Änderungen, aber nicht zuverlässig Ziel, bewusste Nicht-Änderungen, Review-Gates oder den Grund für einen Abbruch. Bei längeren Agentenläufen fehlt dadurch ein belastbarer Arbeitsverlauf.
MCP-Werkzeuge schreiben semantische Ereignisse in ein append-only PostgreSQL-Journal. Technische Hooks ergänzen Session-Fakten über eine lokale, fehlertolerante Outbox. Eine getrennte Projektion macht offene Slices und ihren Status lesbar.
Vor einer Änderung wird ein begrenzter Slice klassifiziert. Fortschritt bleibt sparsam; Entscheidungen, revisionsgebundene Verifikation und das Ergebnis werden explizit abgeschlossen. Ein Session-Ende beendet keinen Slice automatisch.
Das ist zusätzliche Prozess- und Betriebsinfrastruktur. Sie lohnt sich erst, wenn Arbeit mehrere Sessions, Reviews oder Risikogrenzen überspannt. Für ein kleines Repository reichen Issue, Commit und Testprotokoll oft aus.
Oberfläche ·
Zwei reale Slices derselben devMCP-Änderung zeigen den entscheidenden Übergang: Das erste revisionsgebundene Review endet mit drei konkreten Befunden. Der spätere Implementierungsslice weist die korrigierte Revision, das bestandene Re-Review und die erfüllten Gates aus. Integration und Deployment bleiben dort noch bewusst ein eigener Schritt.
Kontrollierte, datierte Ausschnitte: Session- und Slice-IDs, Links, Live-Telemetrie sowie konkrete sicherheitsrelevante Betriebsdetails wurden durch die Auswahl weggelassen. Die Bilder belegen eine Projektion, nicht den heutigen Runtime-Zustand oder ein festes UI-Versprechen.
Kuratiertes Arbeitsgedächtnis
Bewahrt Entscheidungen, Fehlermuster und echten Wiederaufnahmekontext über einzelne Aufgaben hinweg auf.
Wiederverwendbare Erkenntnisse verschwinden in Chats und Notizen. Das Gegenextrem – jede Sitzung vollständig zu speichern – erzeugt jedoch ein lautes, widersprüchliches Gedächtnis.
Ein .NET-MCP-Server speichert kompakte Einträge in PostgreSQL mit pgvector. Semantische Suche wird mit Metadaten wie Projekt, Typ und Scope kombiniert. Temporärer Session-Kontext erhält standardmäßig eine TTL; explizite Supersession-Beziehungen lösen Treffer zu kanonischen Einträgen auf.
Zu Beginn wird nach passendem Wissen gesucht. Gespeichert wird nur bestätigtes, außerhalb des aktuellen Slices nützliches Wissen – oder ein wirklich benötigter Übergabestand. Repository und aktuelle Dokumentation bleiben maßgeblich.
Suche und Query bleiben strikt lesend; abgelaufene Einträge werden nur durch eine explizite Bereinigung gelöscht. Supersession löst Widersprüche dennoch nicht allgemein: Ersetzungen müssen ausdrücklich referenziert werden. Zyklen, ungültige Beziehungen und konkurrierende terminale Nachfolger werden fail-closed als Konflikt behandelt; fehlende Ziele bleiben dagegen diagnostisch sichtbar und erzeugen keinen Platzhalter. Retrieval bleibt probabilistisch und Metadaten brauchen Pflege. Für wenige stabile Notizen ist eine versionierte Markdown-Datei einfacher.
Quellennavigation
Macht Dokumentation, DDL, Code und Endpoint-Kataloge repositoryübergreifend auffindbar, ohne sie zur neuen Wahrheit zu erklären.
Bei mehreren Repositories kostet schon das Finden der zuständigen Quelle Zeit. Freie Volltextsuche bevorzugt zudem häufig den zufällig passenden Text statt des kanonischen Vertrags.
Registrierte Quellen werden synchronisiert, in Dokumente und Chunks zerlegt und über einen Worker indexiert. Ein neuer Source-Stand hält geänderte Dokumente als unveröffentlichte Scan-Kandidaten zurück. Persistente Läufe und ein digestgebundenes Manifest erlauben den atomaren Wechsel erst, wenn die Pflichtjobs und erforderlichen Embeddings dieser Kandidaten vollständig sind.
devMCP liefert den Einstiegspunkt. Bindende Aussagen werden anschließend im Original und bei Bedarf an einer konkreten Revision geprüft. Im aktiven Lifecycle gelten Full- und Delta-Scans getrennt; ein Scan ist erst mit ready veröffentlicht. Ältere Embedding-Lücken können die Source trotzdem degraded lassen. Eine read-only Readiness-Sicht trennt diesen Zustand vom servierten Stand sowie von legacy_unverified und unavailable.
Atomare Publikation verhindert unvollständige neue Source-Stände, aber weder veraltete Eingaben noch semantisch falsche Treffer. Dafür entstehen mehr persistenter Zustand, Schema-Rollforward, Polling und explizite Repair- sowie Maintenance-Pfade. Fehlgeschlagene Scans lassen den alten Stand unangetastet, müssen aber als eigene Readiness-Dimension beobachtet werden. Historische Generationen verschwinden nicht automatisch; ihre Bereinigung bleibt ein separater, geschützter Betriebsakt. In einem einzelnen kleinen Repo ist direkte Suche einfacher.
Tatsächlicher Ablauf
Akasha nach wiederverwendbarem Wissen durchsuchen.
Mit devMCP navigieren, dann das kanonische Original lesen.
Ziel, Grenze und erforderliche Gates im Journal festlegen.
Implementieren, prüfen und Abweichungen sichtbar halten.
Ergebnis und Verifikation im Journal dokumentieren.
Nur dauerhaftes Wissen bewusst nach Akasha übernehmen.
Lokale Infrastruktur
Ein versioniertes, nur lokal gebundenes Aspire Dashboard sammelt Entwicklungslogs, Traces und Metriken mehrerer Anwendungen über OTLP/HTTP. Das hilft bei verteilten Fehlern, ohne daraus ein Produktions-Monitoring zu machen.
Grenze: Container, Exportkonfiguration und Datenvolumen sind zusätzlicher lokaler Betrieb. Für eine einzelne Anwendung ist strukturiertes Logging oft ausreichend.
Weiterentwickeltes Experiment
Eine kleine macOS-Menüleisten-App verwaltet Displays und erzeugt virtuelle Monitore für Remote-Arbeit und UI-Tests. Persistierte Seriennummern halten virtuelle Display-Identitäten über Neustarts stabiler als flüchtige Laufzeit-IDs.
Grenze: Die Lösung verwendet private Apple-APIs, ist nicht App-Store-tauglich und kann durch ein macOS-Update brechen. Das ist eine bewusste Plattformwette, kein allgemeines Display-Framework.
Nichtproduktive Infrastruktur
Ein kleiner, revisionsgebundener Zielaufbau prüft die Anwendung als zusammenhängendes System: statische Release-Artefakte, bereinigte realistische Persistenz, echter Browser, Restore und ein endlicher Aktivierungs- und Rollbackpfad.
Grenze: Die Umgebung ist kein Produktionsklon. Datenrealismus ist nur mit reproduzierbarer Bereinigung, Negativprüfungen und belegtem Wiederanlauf vertretbar; weitere Erweiterungen benötigen eigene Gates.
Erwartbar offline · fest verdrahtet
Eine Referenzinstallation und zwei feste weitere Installationen prüfen dieselben Produktgrenzen mit getrennten Anwendungs-, Daten- und Sitzungskontexten. Der Aufbau bleibt manuell erneuerbar und verzichtet auf Discovery oder dynamische Mandantenauflösung.
Grenze: Getrennte Datenbanken und Rollen beseitigen nicht den gemeinsamen Ausfallbereich der Datenbankprozesse. Sichtbare Konfiguration ersetzt außerdem keinen vollständigen Frontend- und Accessibility-Nachweis.
Private Dokumentationskopie
Freigegebene Markdown-Quellen werden nach einem erfolgreichen devMCP-Sync in einen privaten Vault übernommen. Eine lokale Historie bewahrt konkurrierende Änderungen sichtbar; die synchronisierte Kopie erleichtert Lesen und Review auf mobilen Geräten, schreibt aber nie automatisch in ein Repository zurück.
Grenze: Synchronisation, Konfliktkopien, Plug-in und Backup sind zusätzlicher Betrieb. Die Kopie ist eine Arbeitsoberfläche, keine zweite Source of Truth und kein automatischer Rückschreibkanal.
Werkzeugmuseum
Hier landen Werkzeuge, die real gebaut und verwendet wurden, deren Aufgabe im aktuellen Workflow aber entfallen ist.
Externe Slice-Orchestrierung
Zerlegte größere Arbeiten in kontrollierbare Codex-Runs, als der Agent diese Struktur, ihre Gates und ihre Übergaben noch nicht zuverlässig selbst halten konnte.
Eine .NET-10-CLI plante Modellversuche, prüfte benötigte MCP-Server, startete codex exec, schrieb Laufartefakte und bewertete Checks sowie neue Git-Änderungen gegen explizite Scope-Grenzen.
Im heutigen interaktiven Workflow führt Codex diese Orchestrierung, Revisionsbindung und Verifikation selbst. Die zusätzliche CLI verdoppelte Planung, Zustand und mögliche Fehlerpfade, ohne hier noch denselben Sicherheitsgewinn zu liefern.
Begrenzte Slices, explizite Voraussetzungen, harte Scope-Grenzen und reproduzierbare Checks. Verschwunden ist die zusätzliche Laufzeit, nicht die dahinterliegende Disziplin.
Für unbeaufsichtigte oder streng deterministische Batch-Pipelines kann ein externer Runner weiterhin sinnvoll sein. Retired bedeutet hier: für diesen Workflow ersetzt.
Quellenlage