Systemnotizen · Stand 06.10.2026
Der zentrale Codex-Arbeitsplatz ist inzwischen selektiv versioniert. Portable Regeln, Werkzeuge, Shell- und Laufzeitverträge lassen sich gezielt prüfen und installieren; Logins, Secrets, App-Zustand und laufende Automationen bleiben bewusst an ihren jeweiligen Rechner gebunden. Zugleich hat CodexJournal ungenutzte Koordinations- und Review-Hilfsschichten wieder entfernt.
Seit 04.09.2026
Ein privates Repository beschreibt jetzt die portablen Teile des Codex-Arbeitsplatzes: globale Arbeitsregeln, persönliche Skills und Hooks, lokale Quellennavigation, einen markierten Shell-Block, ausgewählte Laufzeitdefinitionen sowie einen prüfbaren macOS-Bootstrap. Dry-runs, ein mutierungsfreier Doctor und konfliktbewusste Installer ersetzen die frühere Sammlung einzelner manueller Kopierschritte.
Auf dem führenden Entwicklungsrechner entsprechen die globalen Regeln, der verwaltete Shell-Bereich und ausgewählte lokale Laufzeitdefinitionen dem versionierten Stand. Persönliche Skills folgen demselben Installationsmodell, zwei von ihnen enthalten dort aber bereits neuere lokale Ergänzungen. Auf einem zweiten Rechner wurden einzelne geprüfte Repository-Stände bewusst übernommen; ein read-only Abgleich macht Abweichungen sichtbar, autorisiert aber kein Update. Vollständige Parität ist nicht belegt. Sessions, Memories, Zugangsdaten, Trust-Entscheidungen und Live-Automationen werden nicht gespiegelt.
Die selektive Installation macht Wiederaufbau und Drift prüfbarer, ohne lokale Identität mit Konfiguration zu verwechseln. Sie ist trotzdem kein vollständig deklaratives Maschinenmanagement: Sicherheitssoftware, Anmeldungen, Toolchains und laufende Dienste brauchen weiterhin bewusste lokale Schritte. Jeder neue verwaltete Bereich vergrößert auch die Migrations- und Konfliktfläche.
Zusätzlicher technischer Stand
CodexJournal hat den lokalen Review-Companion, Browseraktionen, Shared Notes und die strukturierte Kontextbewertung aus der aktiven Oberfläche entfernt. Historische Ereignisse und ihre alten Verträge bleiben lesbar; neue Slices benötigen diese Zustände nicht mehr.
Ein erforderlicher unabhängiger Review startet als getrennte, read-only Codex-Session gegen den festgelegten Commit. Das Journal bewahrt Verifikation und Befund, transportiert den Reviewer aber nicht mehr selbst. Der Beschwerdebriefkasten bleibt davon getrennt und optional.
Der Launcher war technisch eng begrenzt, verdoppelte aber Zustellung, Zustandsmodell und Fehlerpfade für eine Fähigkeit, die Codex inzwischen direkt bereitstellt. Seine Entfernung ist kein Scheitern der Revisionsbindung, sondern die Trennung von notwendigem Reviewvertrag und ersetzbarer Transporttechnik.
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 Ziel, Entscheidungen, Verifikation und Ergebnis einer Arbeitseinheit fest, ohne daraus eine parallele Prozesssteuerung zu machen.
Git zeigt Änderungen, aber nicht zuverlässig Ziel, bewusste Nicht-Änderungen, Review-Ergebnisse oder den Grund für einen Abbruch. Zusätzliche Koordinationsflächen können dieses Problem jedoch selbst verdoppeln.
MCP-Werkzeuge schreiben semantische Ereignisse in ein append-only PostgreSQL-Journal; technische Hooks ergänzen Session-Fakten. Historische Change-Control- und Review-Launcher-Ereignisse bleiben lesbar. Shared Notes, strukturierte Kontextbewertung, Launcher und Companion gehören nicht mehr zur aktiven Werkzeugfläche.
Der normale Weg ist Aufgabe, Slice, Implementierung, Tests, bei Bedarf ein unabhängiger Review in einer getrennten Codex-Session und Abschluss. Das Journal hält Nachweise fest, autorisiert aber keine Repository-Aktion. Temporäre Ressourcen werden vor dem Abschluss bewusst aufgeräumt oder übergeben.
Auch der kleinere Vertrag bleibt zusätzliche Prozess- und Betriebsinfrastruktur. Für kurze Arbeiten reichen Commit und Tests oft aus. Der Write-only-Briefkasten bleibt ein optionales Signal und darf weder Journalentscheidung noch Gate werden.
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.
Originalquellennavigation
Ordnet Projekt- und Source-Keys direkt lokalen Repository-Originalen zu und durchsucht Dokumentation und DDL mit ripgrep.
Repositoryübergreifende Arbeit braucht einen stabilen Einstieg, ohne vor jeder Aussage einen entfernten Index, Embeddings oder einen veröffentlichten Scanstand vorauszusetzen.
Ein versioniertes Mapping verbindet Git-Origins, mögliche Checkout-Wurzeln und freigegebene Dokument- oder DDL-Pfade. Der aktuelle passende Worktree gewinnt; fehlende oder mehrdeutige Quellen brechen sichtbar ab. Suche läuft ohne Index, persistenten Dokument- oder Inhaltscache, Auto-Clone oder Netzwerk-Fallback direkt auf den Dateien.
Nach dem Akasha-Kontext wird zuerst das Projekt lokal aufgelöst. Dokumentation und DDL werden in den gemappten Originalen gesucht; für Code und nicht gemappte Quellen folgt normales ripgrep im aufgelösten Checkout. Erst der gelesene Originalstand autorisiert die Aussage.
Determinismus und geringe Betriebsfläche kosten semantisches Ranking, zentrale Veröffentlichung und maschinenübergreifende Verfügbarkeit. Das Mapping muss gepflegt werden und setzt lokale Checkouts voraus. Für große, verteilte Korpora kann ein Index weiterhin sinnvoller sein.
Tatsächlicher Ablauf
Akasha nach wiederverwendbarem Wissen durchsuchen.
Mit docs-find das lokale Original auflösen und direkt lesen.
Ziel und Grenze festlegen; einen unabhängigen Review nur nach Risiko, Auftrag oder bindender Regel einsetzen.
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-Originale werden nach einer Änderung direkt über dasselbe lokale Dokument-Mapping in einen privaten Vault übernommen. Eine lokale Historie bewahrt konkurrierende Obsidian-Änderungen sichtbar; die Kopie schreibt nie automatisch in ein Repository zurück.
Grenze: Synchronisation, Konfliktkopien, Plug-in und Backup bleiben zusätzlicher Betrieb. Die direkte Kopplung entfernt nur den Index als Zwischenstufe; Obsidian bleibt eine abgeleitete Arbeitsoberfläche.
Versionierter Arbeitsplatz
Ein privater, prüfbarer Vertrag bündelt die portablen Teile des Entwicklungsrechners und installiert sie komponentenweise. Die führende Maschine autorisiert Änderungen; weitere Geräte dürfen nur bewusst ausgewählte Git-Stände übernehmen.
Grenze: Logins, Secrets, Sessions, Memories, breite Trust-Entscheidungen, Live-Automationen und hardwarespezifische Laufzeitdaten bleiben absichtlich außerhalb dieses Vertrags.
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.
Indexierte Quellennavigation
Synchronisierte Dokumentation, DDL, Code und Endpoints in einen semantisch durchsuchbaren Dienst mit atomarer Veröffentlichung, Readiness und Repairpfaden.
Registrierte Quellen wurden versioniert erfasst, in unveröffentlichte Kandidaten überführt und erst nach vollständigen Pflichtjobs atomar sichtbar. Manifeste, Readiness und Reparatur machten unvollständige Stände diagnostizierbar.
Der aktuelle Workflow muss bindende Aussagen ohnehin am lokalen Original prüfen. Für die vorhandenen Repositories erzeugte der Index mehr Zustands-, Betriebs- und Aktualisierungsarbeit, als sein semantisches Ranking sparte.
Stabile Projekt- und Source-Keys, explizite Originalquellenrollen, sichtbare Drift und die Trennung von Navigation und Autorität. Ersetzt wurde die Laufzeit, nicht die Provenienzdisziplin.
Für große, verteilte oder überwiegend semantisch erschlossene Korpora kann ein veröffentlichter Index wieder sinnvoll sein. Die deaktivierte Definition bleibt deshalb als begrenzter Rückfall erhalten.
Quellenlage