Original vor Index
Suche beschleunigt das Finden. Sie autorisiert keine Aussage und ersetzt weder Code noch DDL oder Laufzeitbeleg.
Systemnotizen · Stand 12.08.2026
Werkzeuge für nachvollziehbare Entwicklungsarbeit.
macmade.dev ist eine technische Bestandsaufnahme selbst gebauter Infrastruktur: nicht als Produktportfolio, sondern als Erklärung dafür, warum drei kleine Systeme entstanden sind – und welchen Preis ihre Trennung hat. Jeder Stand ist eine versionierte Momentaufnahme; spätere Änderungen sollen auch zeigen, welche Trade-offs kleiner wurden, neu entstanden oder ganz verschwanden.
Das System
Drei Arten von Zustand, bewusst nicht vermischt.
bindendRepository & Runtimeaktuelle technische Wahrheit
findendevMCPindexierte Navigation
arbeitenCodexJournaloperativer Verlauf
kuratiertAkashawiederverwendbares Wissen
Der letzte Übergang ist absichtlich manuell. Ein abgeschlossenes Journal-Ereignis wird nicht automatisch zu dauerhaftem Wissen.
Ereignis vor Erzählung
Das Journal speichert kleine, typisierte Nachweise statt eines vollständigen Transkripts der Arbeit.
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
Hält fest, was eine Arbeitseinheit erreichen soll, welche Entscheidungen gefallen sind und woran ihr Ergebnis geprüft wurde.
append-only EreignissePostgreSQLMCP + lokale Hooks
Auslöser
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.
Mechanik
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.
Im Ablauf
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.
Grenze / Trade-off
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 ·
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 ↗
02 · Re-Review · Vollbild ↗
02
Kuratiertes Arbeitsgedächtnis
Akasha
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
Quellennavigation
devMCP
Macht Dokumentation, DDL, Code und Endpoint-Kataloge repositoryübergreifend auffindbar, ohne sie zur neuen Wahrheit zu erklären.
Scan-Kandidaten + Manifestatomare PublikationReadiness + Repair
Auslöser
Bei mehreren Repositories kostet schon das Finden der zuständigen Quelle Zeit. Freie Volltextsuche bevorzugt zudem häufig den zufällig passenden Text statt des kanonischen Vertrags.
Mechanik
Registrierte Quellen werden synchronisiert, in Dokumente und Chunks zerlegt und über einen Worker indexiert. Ein neuer Source-Stand hält geänderte Dokumente als unveröffentlichte Scan-Kandidaten zurück. Persistente Läufe und ein digestgebundenes Manifest erlauben den atomaren Wechsel erst, wenn die Pflichtjobs und erforderlichen Embeddings dieser Kandidaten vollständig sind.
Im Ablauf
devMCP liefert den Einstiegspunkt. Bindende Aussagen werden anschließend im Original und bei Bedarf an einer konkreten Revision geprüft. Im aktiven Lifecycle gelten Full- und Delta-Scans getrennt; ein Scan ist erst mit ready veröffentlicht. Ältere Embedding-Lücken können die Source trotzdem degraded lassen. Eine read-only Readiness-Sicht trennt diesen Zustand vom servierten Stand sowie von legacy_unverified und unavailable.
Grenze / Trade-off
Atomare Publikation verhindert unvollständige neue Source-Stände, aber weder veraltete Eingaben noch semantisch falsche Treffer. Dafür entstehen mehr persistenter Zustand, Schema-Rollforward, Polling und explizite Repair- sowie Maintenance-Pfade. Fehlgeschlagene Scans lassen den alten Stand unangetastet, müssen aber als eigene Readiness-Dimension beobachtet werden. Historische Generationen verschwinden nicht automatisch; ihre Bereinigung bleibt ein separater, geschützter Betriebsakt. In einem einzelnen kleinen Repo ist direkte Suche einfacher.
Tatsächlicher Ablauf
Ein kleiner Kontrollkreis, kein autonomes Wissenssystem.
- 01Kontext
Akasha nach wiederverwendbarem Wissen durchsuchen.
- 02Quelle
Mit devMCP navigieren, dann das kanonische Original lesen.
- 03Slice
Ziel, Grenze und erforderliche Gates im Journal festlegen.
- 04Arbeit
Implementieren, prüfen und Abweichungen sichtbar halten.
- 05Abschluss
Ergebnis und Verifikation im Journal dokumentieren.
- 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.
Werkzeugmuseum
Nicht jede hilfreiche Schicht muss bleiben.
Hier landen Werkzeuge, die real gebaut und verwendet wurden, deren Aufgabe im aktuellen Workflow aber entfallen ist.
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.
Quellenlage
Was dieser Stand behauptet – und was nicht.
Belegt durch
- aktuelle Repository-Dokumentation und Architekturentscheidungen
- Implementierung, Tests und veröffentlichte Werkzeugverträge
- Live-Navigation über die tatsächlich erreichbaren MCP-Werkzeuge
- 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
Chronik-Vertrag v1veröffentlichter Originalstand d792569