Systemnotizen · Stand 04.09.2026
CodexJournal dokumentiert den Arbeitsverlauf wieder ohne verpflichtende Change-Control-Matrix. Historische Level und Gates bleiben lesbar, steuern neue Slices aber nicht mehr. Optionale Reibungssignale und experimentelle Shared Notes sind bewusst getrennt – eine neue Oberfläche ist noch kein neuer Pflichtprozess.
Seit 01.09.2026
Neue Slices benötigen keine L1–L4-Klassifikation und keine allgemeine Gate-Matrix mehr. Die historischen Ereignisse bleiben unverändert lesbar. Neu hinzu kamen ein getrennter Write-only-Briefkasten für optionale Reibungssignale und eine experimentelle persistente Read-/Append-Fläche; beide liegen außerhalb des Journal- und Slice-Modells.
Arbeit läuft von Aufgabe und begrenztem Slice über Implementierung und Tests zum risikobasierten Review und Abschluss. Zusätzliche Task- oder Kontextmarker werden nur bei echtem Nutzen gesetzt. Der Briefkasten bleibt optional; für eine regelmäßige Nutzung der Shared Notes gibt es noch keinen Beleg.
Git, Journal, Tests und Review hatten denselben Zustand teilweise parallel modelliert. Ihre Rollen klar zu trennen ist belastbarer als immer neue Pflichtnachweise einzuführen. Auch Shared Notes verdienen noch keine Koordinationssemantik: Erst konkrete Nutzung kann zeigen, ob die kleine Fläche mehr löst als sie an neuem Zustand erzeugt.
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-Ergebnisse 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. Historische Change-Control-Daten bleiben lesbar, ihre Level und Gates gehören aber nicht mehr zur aktiven Werkzeugfläche. Ein Write-only-Briefkasten und experimentelle Shared Notes liegen als getrennte Nebenflächen außerhalb des Slice-Verlaufs.
Der normale Weg ist Aufgabe, Slice, Implementierung, Tests, bei Bedarf ein risikobasierter unabhängiger Review und Abschluss. Das Journal dokumentiert diesen Verlauf, autorisiert aber keine Repository-Aktion und verlangt keine allgemeine Risikoklassifikation.
Auch der kleinere Vertrag bleibt zusätzliche Prozess- und Betriebsinfrastruktur. Für kurze Arbeiten reichen Commit und Tests oft aus. Der Briefkasten ist nur ein optionales Signal; Shared Notes sind noch kein Koordinationssystem und müssten ihren Nutzen erst in tatsächlicher Verwendung zeigen.
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.
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