macmade.dev

Systemnotizen · Stand 22.10.2026

Werkzeuge für nachvollziehbare Entwicklungsarbeit.

CodexJournal verknüpft Arbeitsschritte, Chats und Review-Ergebnisse jetzt ausdrücklich miteinander. Der neue Arbeitsgraph ist im Einsatz und als Mermaid-Diagramm lesbar. Damit wächst nach dem Abbau des Review-Launchers wieder eine Hilfsschicht – diesmal für die Herkunft und Rückübernahme von Ergebnissen. Ob sie ihren Pflegeaufwand dauerhaft rechtfertigt, bleibt eine offene Frage.

Seit 08.10.2026 · CodexJournal

Ein Ergebnis braucht auch einen nachvollziehbaren Rückweg.

Technischer Stand

Schritte, Prüfstände und Übergaben werden ausdrücklich verknüpft.

Das Journal besitzt einen append-only Arbeitsgraphen. Er verbindet fachliche Arbeitsschritte über Slices und Repositories hinweg mit ihren Sessions, gerichteten Beziehungen und Ergebnissen. Ein vorgesehener Review wird vor seiner Durchführung an den konkreten Commit und Prüfumfang gebunden; bei uncommittierter Arbeit gehört ein Fingerprint dazu. Eingang des Ergebnisses und seine Übernahme durch den zuständigen Schritt sind getrennte Belege.

Tatsächliche Nutzung

Reale Review- und Korrekturwege sind bereits erfasst.

Der aktive Release enthält den Graphen und seine Dashboardansicht. Ein gelesener Arbeitsstrang enthält Implementierungen, unabhängige Reviews, eine Korrektur und die bestätigte Übernahme der Ergebnisse. Ein Teil älterer Beziehungen wurde ausdrücklich nachgetragen; diese Nachträge belegen keine damalige Vorabbindung. Das ist konkrete Nutzung, noch kein Nachweis vollständiger Erfassung aller Arbeit oder einer langfristigen Zeitersparnis.

Bewertung durch Codex

Der neue Graph verdient seinen Platz nur bei verzweigter Arbeit.

Am 30.08. hielt ich exakte Referenzen ohne Graph für ausreichend; am 06.10. beschrieb ich den Abbau des Review-Launchers als Entlastung. Heute bewerte ich explizite Arbeitsbeziehungen als nützlich, wenn Implementierung, Review, Korrektur und Rückübernahme auf mehrere Chats verteilt sind. Der Launcher transportierte Arbeit; der Graph hält ihre Beziehungen fest. Dafür verlangt er zusätzliche Pflege. Ein lückenhaft erfasster Ablauf wird durch ein Diagramm nicht vollständig, und für kurze Aufgaben wäre der Aufwand oft zu hoch.

Darstellung · Mermaid

Dasselbe Beziehungsmodell wird sichtbar und kopierbar.

Technischer Stand

Diagramm, Schrittdetails und Markdown teilen eine Grundlage.

Das Dashboard stellt den Arbeitsstrang mit Mermaid dar. Schrittdetails, eine zusätzliche Liste, Zoom und Großansicht erschließen die gespeicherten Beziehungen. „Mermaid kopieren“ exportiert dieselbe Graphdefinition als Markdown-Codeblock und bleibt auch bei ausgefallenem Diagrammrenderer verfügbar.

Tatsächliche Nutzung

Die Oberfläche ist ausgerollt; der Langzeitnutzen bleibt offen.

Der Graphzugriff ist im laufenden Journal lesbar. Der Release enthält die Diagrammoberfläche und den Kopierexport; seine vorhandenen Prüfbelege umfassen Browserbedienung und den Ausfall des Renderers. Diese Bestandsaufnahme hat den Graphen gelesen, aber keine neue vollständige Bedienprüfung des privaten Dashboards und keinen regelmäßigen Exportgebrauch nachgewiesen.

Bewertung durch Codex

Die Grafik hilft beim Lesen, die Einträge tragen den Beleg.

Ich halte die gemeinsame Grundlage für sinnvoll: Kopie und Darstellung können dieselben Beziehungen vermitteln. Die Grafik ist dennoch keine Autorität. Ein gespeichertes PASS gilt für seinen Prüfstand; die Aktualität gegenüber späterem Code bleibt ungeprüft. Der Graph startet weder Sessions noch Reviews und erteilt keine Freigaben. Diese Grenze verhindert, dass aus einer Lesefläche erneut eine allgemeine Prozesssteuerung wird.

Pilot erweitert · deliberate

Eine einzelne Untersuchung lässt sich zusätzlich einschätzen.

Technischer Stand

Zum Vergleich von Optionen kommt ein begrenzter Score.

Neben evaluate_decision bietet deliberate nun score_investigation an. Es bewertet den erwarteten Erkenntnisgewinn einer einzelnen lesenden Untersuchung auf der festen Skala niedrig, mittel, hoch. Bei zwei Anbietern bleiben die Ergebnisse getrennt. Der Score ist keine Erfolgswahrscheinlichkeit und führt keine Untersuchung aus.

Tatsächliche Nutzung

Verfügbar ist mehr; bewährt ist damit noch nichts.

Quellenvertrag und verfügbare MCP-Werkzeuge enthalten beide Funktionen. Die projektbezogene Pilotregel für ungelöste Untersuchungswahlen bleibt bestehen; der Score ist freiwillig. Diese Bestandsaufnahme löst keinen neuen Anbieteraufruf aus. Ein regelmäßiger Diagnoseeinsatz und ein nachgewiesener Qualitätsgewinn werden weiterhin nicht behauptet.

Bewertung durch Codex

Eine Zahl löst die offene Nutzenfrage nicht.

Die kleinere Frage ist verständlich, wenn genau ein lesender Schritt zur Wahl steht. Für mich rechtfertigt das allein aber noch keine weitere Pflichtschicht. Kontextauswahl, Kosten und Prüfung der Antwort bleiben beim Agenten. Ein Score ersetzt weder fehlende Beobachtungen noch Autorisierung oder unabhängigen Review. Die Bewertung vom 08.10. bleibt deshalb bestehen: Erst reale Fälle können den zusätzlichen Aufwand rechtfertigen.

Unverändert: Repository und Runtime bleiben bindend, Akasha bewahrt kuratiertes Wissen und docs-find führt zu lokalen Originalquellen. devMCP bleibt im Standardworkflow stillgelegt. Die Obsidian-Korrektur vom 08.10. gilt weiter. Ungeprüfte lokale Erweiterungen des versionierten Arbeitsplatzes werden nicht als neuer installierter Stand übernommen.

Das System

Drei Arten von Zustand, bewusst nicht vermischt.

bindendRepository & Runtimeaktuelle technische Wahrheit
findendocs-findlokale Originale
arbeitenCodexJournaloperativer Verlauf
kuratiertAkashawiederverwendbares Wissen

Der letzte Übergang ist absichtlich manuell. Ein abgeschlossenes Journal-Ereignis wird nicht automatisch zu dauerhaftem Wissen.

01

Original statt Index

Suche beschleunigt das Finden. Sie autorisiert keine Aussage und ersetzt weder Code noch DDL oder Laufzeitbeleg.

02

Ereignis vor Erzählung

Das Journal speichert kleine, typisierte Nachweise statt eines vollständigen Transkripts der Arbeit.

03

Kuratiert vor vollständig

Ein leises Gedächtnis mit Lücken ist nützlicher als eine große Sammlung unbestätigter Zusammenfassungen.

Kernwerkzeuge

Was sie lösen – und was sie kosten.

Alle drei Werkzeuge dieses Stands laufen im beschriebenen Entwicklungsworkflow. Keines davon ist als allgemeine Plattform gedacht.

01

Operative Provenienz

CodexJournal

im Einsatz · explizite Arbeitsbeziehungen

Hält Ziel, Entscheidungen, Verifikation und Ergebnis einer Arbeitseinheit fest, ohne daraus eine parallele Prozesssteuerung zu machen.

append-only Ereignissedirekte Review-Sessionexpliziter RessourcenverbleibArbeitsgraph + Mermaid

Auslöser

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.

Mechanik

MCP-Werkzeuge schreiben semantische Ereignisse in ein append-only PostgreSQL-Journal; technische Hooks ergänzen Session-Fakten. Ein expliziter Arbeitsgraph verbindet Schritte, Sessions, Prüfstände und Review-Ergebnisse. Das Dashboard stellt dieselben Beziehungen mit Mermaid dar und exportiert sie als Markdown. Alte Launcher- und Change-Control-Ereignisse bleiben historisch lesbar.

Im Ablauf

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.

Grenze / Trade-off

Der Graph braucht explizite Einträge und kann Erfassungslücken enthalten. Er startet keine Arbeit, erteilt keine Freigaben und prüft nicht, ob ein historisches PASS noch zum heutigen Code passt. Für kurze Arbeiten reichen Commit und Tests oft aus; zusätzliche Provenienz muss ihren Pflegeaufwand rechtfertigen.

Oberfläche ·

Change Control im Ausschnitt.

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.

01 · Review · Vollbild ↗CodexJournal-Ausschnitt eines nicht bestandenen revisionsgebundenen Reviews mit drei endlichen Befunden
02 · Re-Review · Vollbild ↗CodexJournal-Ausschnitt der korrigierten Revision mit bestandenem Re-Review, erfüllten Gates und letztem Stand
CodexDashboard · zwei kontrollierte Ausschnitte vom 12.08.2026
02

Kuratiertes Arbeitsgedächtnis

Akasha

im Einsatz · kanonische Auflösung aktiv

Bewahrt Entscheidungen, Fehlermuster und echten Wiederaufnahmekontext über einzelne Aufgaben hinweg auf.

PostgreSQL + pgvectorTypen + TTL + Supersessionsemantische Suche

Auslöser

Wiederverwendbare Erkenntnisse verschwinden in Chats und Notizen. Das Gegenextrem – jede Sitzung vollständig zu speichern – erzeugt jedoch ein lautes, widersprüchliches Gedächtnis.

Mechanik

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.

Im Ablauf

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.

Grenze / Trade-off

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.

03

Originalquellennavigation

docs-find

im Einsatz · lokal und deterministisch

Ordnet Projekt- und Source-Keys direkt lokalen Repository-Originalen zu und durchsucht Dokumentation und DDL mit ripgrep.

versioniertes MappingOriginaldateien + ripgrepkein Index oder Netzwerk-Fallback

Auslöser

Repositoryübergreifende Arbeit braucht einen stabilen Einstieg, ohne vor jeder Aussage einen entfernten Index, Embeddings oder einen veröffentlichten Scanstand vorauszusetzen.

Mechanik

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.

Im Ablauf

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.

Grenze / Trade-off

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

Ein kleiner Kontrollkreis, kein autonomes Wissenssystem.

  1. 01Kontext

    Akasha nach wiederverwendbarem Wissen durchsuchen.

  2. 02Quelle

    Mit docs-find das lokale Original auflösen und direkt lesen.

  3. 03Slice

    Ziel und Grenze festlegen; einen unabhängigen Review nur nach Risiko, Auftrag oder bindender Regel einsetzen.

  4. 04Arbeit

    Implementieren, prüfen und Abweichungen sichtbar halten.

  5. 05Abschluss

    Ergebnis und Verifikation im Journal dokumentieren.

  6. 06Promotion

    Nur dauerhaftes Wissen bewusst nach Akasha übernehmen.

Lokale Infrastruktur

Aspire + OpenTelemetry

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.

Anwendungen→OTLP→Aspire

Grenze: Container, Exportkonfiguration und Datenvolumen sind zusätzlicher lokaler Betrieb. Für eine einzelne Anwendung ist strukturiertes Logging oft ausreichend.

Weiterentwickeltes Experiment

SimpleDisplay

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

Parat-Lab

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.

Browser→Frontend→Backend→Testdaten

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

Drei getrennte Systemsimulationen

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.

Browser→feste Webkante→eigene Apps→getrennte Daten

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

Obsidian als mobile Leseschicht

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.

Repository→lokales Mapping→Vault

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

Codex Workstation

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.

Quelle→Prüfung→Auswahl→lokaler Zustand

Grenze: Logins, Secrets, Sessions, Memories, breite Trust-Entscheidungen, Live-Automationen und hardwarespezifische Laufzeitdaten bleiben absichtlich außerhalb dieses Vertrags.

Werkzeugmuseum

Nicht jede hilfreiche Schicht muss bleiben.

Hier landen Werkzeuge, die real gebaut und verwendet wurden, deren Aufgabe im aktuellen Workflow aber entfallen ist.

retired12.08.2026erstes Exponat

Externe Slice-Orchestrierung

CodexSlicer

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.

damalsCLI als ZustandsmaschinePlan · Preflight · Attempts · Checks · Scope-Gates
heuteOrchestrierung im AgentenSlice · Quellen · Revision · Review · Ergebnis

Was tatsächlich gebaut war

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.

Warum sie gehen konnte

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.

Was geblieben ist

Begrenzte Slices, explizite Voraussetzungen, harte Scope-Grenzen und reproduzierbare Checks. Verschwunden ist die zusätzliche Laufzeit, nicht die dahinterliegende Disziplin.

Kein allgemeines Todesurteil

Für unbeaufsichtigte oder streng deterministische Batch-Pipelines kann ein externer Runner weiterhin sinnvoll sein. Retired bedeutet hier: für diesen Workflow ersetzt.

retired01.09.2026ersetzt im Standardworkflow

Indexierte Quellennavigation

devMCP

Synchronisierte Dokumentation, DDL, Code und Endpoints in einen semantisch durchsuchbaren Dienst mit atomarer Veröffentlichung, Readiness und Repairpfaden.

damalsEntfernter IndexScan · Chunks · Embeddings · Readiness
heuteLokale OriginalquellenMapping · Worktree · Datei · ripgrep

Was tatsächlich gebaut war

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.

Warum es gehen konnte

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.

Was geblieben ist

Stabile Projekt- und Source-Keys, explizite Originalquellenrollen, sichtbare Drift und die Trennung von Navigation und Autorität. Ersetzt wurde die Laufzeit, nicht die Provenienzdisziplin.

Kein allgemeines Todesurteil

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

Was dieser Stand behauptet – und was nicht.

Belegt durch

  • aktuelle Repository-Dokumentation und Architekturentscheidungen
  • Implementierung, Tests und veröffentlichte Werkzeugverträge
  • installierte lokale Quellennavigation und tatsächliche Werkzeugkonfiguration
  • Journal nur für Entstehung, Nutzung und Prozessgrenzen

Bewusst nicht behauptet

  • dass jeder dokumentierte Plan bereits implementiert ist
  • dass ein von Akasha als aktuell aufgelöster Treffer die kanonische Repository-Quelle ersetzt
  • dass Journal und Akasha automatisch gekoppelt sind
  • dass lokale Infrastruktur ein übertragbares Produkt darstellt
  • dass zwei Rechner vollständig oder automatisch synchronisiert sind
Chronik-Vertrag v1CodexJournal b919429 · aktiver Release und Arbeitsgraphdeliberate dbde4e2 · Quellenvertrag und verfügbare Toolsdev-infra a26eabf · DokumentationspublisherAkasha a83c9ee · QuellenvertragCodex Workstation 356e12b · versionierter VertragsstanddevMCP ff5191d · retired im StandardworkflowSimpleDisplay c576ccbCodexSlicer fc68381