Systemnotizen · Stand 08.10.2026
Dieser Stand korrigiert eine falsche Beschreibung der mobilen Dokumentationskopie. Zugleich macht das Journal lange Meldungen und nächste Schritte besser lesbar. Eine neue Modellberatung für lesende Untersuchungen ist als Pilot konfiguriert; ihr Nutzen im Routineeinsatz ist noch nicht belegt.
Korrektur · 08.10.2026
Der Dokumentationspublisher überschreibt verwaltete Markdown-Kopien im privaten Vault mit dem Original. Er erzeugt weder Konfliktkopien noch Git-Snapshots oder Commits. Die Historie liegt im Quellrepository; persönliche Notizen außerhalb der verwalteten Kopien bleiben unberührt.
Der Stand vom 06.10. übernahm die Beschreibung einer lokalen Historie und von Konfliktkopien aus den älteren Momentaufnahmen vom 01.09. und 04.09. Die Umstellung war bereits seit dem 05.09. im Publisher enthalten und wurde bei der Bestandsaufnahme vom 06.10. übersehen. Heute wurden Dokumentation und Implementierung erneut geprüft. Ein neuer Synchronisationslauf ist damit nicht belegt; die historischen Aussagen bleiben lesbar.
Für eine mobile Leseschicht ist das Überschreiben einfacher als eine zweite Bearbeitungshistorie. Es bedeutet aber, dass Änderungen an verwalteten Kopien bei der nächsten Publikation verloren gehen. Meine frühere Beschreibung versprach einen Schutz, den dieser Stand nicht bietet. Kanonische Quellen müssen auch eine vertraute Erzählung korrigieren können.
Seit 06.10.2026 · CodexJournal
Lange Journal-Meldungen erscheinen als kurze Vorschau mit aufklappbarem Volltext und erhalten ihre Absätze. Gespeicherte nächste Schritte bei teilweisen oder blockierten Ergebnissen werden unabhängig vom begrenzten Ereignisverlauf gelesen. Fortsetzung oder Abschluss blendet den alten Schritt aus.
Die neue Fassung ist veröffentlicht. Offene Punkte stehen in der Detailansicht vor dem letzten Stand; lange Meldungen lassen sich vollständig öffnen. Daraus entsteht weder ein neuer Reviewstatus noch eine weitere Pflichtklassifikation.
Mehr gespeicherter Text ist noch kein besserer Überblick. Eine Vorschau mit zugänglichem Volltext und ein eigener nächster Schritt helfen beim Wiederaufnehmen, ohne den Journalvertrag zur Prozesssteuerung auszubauen. Die Oberfläche kann einen unklar geschriebenen Schritt trotzdem nicht reparieren.
Neuer Pilot · deliberate
Der lokale MCP-Server deliberate gibt mit evaluate_decision eine zusätzliche Bewertung vorgegebener Untersuchungsoptionen. Er kann einen oder zwei Modellanbieter konsultieren, untersucht selbst aber keine Dateien und führt keine Empfehlung aus. Frage, Kontext und Optionen werden an die ausgewählten Anbieter weitergegeben.
Der Server ist im lokalen Codex-Client konfiguriert. In seinem eigenen Repository gilt eine Pilotregel für mehrere plausible lesende Untersuchungen, die sich anhand der vorhandenen Fakten nicht klar priorisieren lassen. Außerhalb davon bleibt die Nutzung freiwillig. Ein regelmäßiger Diagnoseeinsatz und ein nachgewiesener Qualitätsgewinn werden hier nicht behauptet.
Ein weiterer Blick kann bei einer offenen Untersuchungswahl helfen. Er kostet aber Zeit, Modellaufrufe und eine bewusste Auswahl des weitergegebenen Kontexts. Übereinstimmende Anbieterantworten beweisen keine Richtigkeit. Ich würde diese Schicht erst dann als etabliertes Werkzeug bewerten, wenn reale Fälle ihren Mehrwert zeigen; Autorisierung und unabhängiger Review bleiben beim bisherigen Vertrag.
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 über das lokale Dokument-Mapping in einen privaten Vault kopiert. Beim Publizieren werden verwaltete Kopien mit der Repository-Fassung überschrieben, auch nach lokalen Änderungen. Der Publisher erzeugt keine Konfliktkopien oder eigene Historie und schreibt nicht ins Repository zurück.
Grenze: Änderungen an verwalteten Kopien können bei der nächsten Publikation verloren gehen. Synchronisation, Plug-in und Backup bleiben zusätzlicher Betrieb. Eine lokale Publikation allein belegt noch keine Synchronisation auf ein mobiles Gerät.
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