Systemnotizen · Stand 01.09.2026
Die Standardnavigation zu Dokumentation und DDL ist wieder eine lokale, deterministische Dateisuche. Der frühere Index bleibt als Rückfallidee dokumentiert, trägt aber weder den normalen Arbeitsbeginn noch die mobile Lesekopie. Weniger Suchmagie bedeutet hier vor allem: weniger verteilten Zustand.
Seit 30.08.2026
Eine installierte Dateisuche löst Projekt- und Source-Keys auf konkrete Repository-Originale auf und durchsucht Dokumentation sowie DDL direkt mit ripgrep. Sie besitzt keinen Index, persistiert keinen Dokument- oder Inhaltscache und nutzt keinen Netzwerk-Fallback. Auch der Obsidian-Publisher bezieht seine freigegebenen Quellen jetzt aus diesem Mapping statt aus einem abgeschlossenen devMCP-Lauf.
Der Arbeitsbeginn führt nach der Akasha-Suche über die lokale Originalquellennavigation und anschließend direkt in Datei, Code oder DDL. Die devMCP-Definition bleibt als reversibler Rückfall erhalten, ist im Normalbetrieb aber deaktiviert. Die mobile Lesekopie wird nach Dokumentänderungen separat veröffentlicht; ein Indexlauf ist weder Trigger noch Gate.
Für die überschaubare Zahl lokaler Repositories wiegen deterministische Pfade und sichtbare Fehler schwerer als semantisches Ranking. Der Index brachte Kandidatenzustand, Embeddings, Readiness und Repair in einen Ablauf, der am Ende ohnehin das Original lesen musste. Verloren gehen bequeme semantische und maschinenübergreifende Suche; bei einem größeren Korpus kann diese Rechnung deshalb wieder anders ausfallen.
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.
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, 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-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