Die Hardware und die Idee

M5Stack StackChan, CoreS3-Variante von OpenELAB. ESP32-S3, 240 MHz Dual-Core, 16 MB Flash, 8 MB PSRAM, zwei Feetech SCS0009-Servos im Hals für Yaw und Pitch, 2-Zoll-IPS-Display, GC0308-Kamera, 12 RGB-LEDs, Dual-Mikrofone. Die Idee dahinter: meiner bestehenden Desktop-KI-Assistentin VINCI ein physisches Gesicht geben, statt sie nur im Chat-Fenster leben zu lassen. Ein Gerät, das mein Smart Home kennt, mein Wetter, meinen Kalender, und das alles mit Servo-Motoren statt nur mit Text.

Anlauf 1: neun Stunden, keine Custom Firmware

Der erste Versuch war Custom Firmware mit vollständiger Kontrolle über Servos, Wake-Word und Persönlichkeit. Start mit AI_StackChan_Ex, einem Arduino/PlatformIO-Framework. M5Unified 0.2.7 hat sich mit der OpenELAB-Boardvariante nicht vertragen, Backlight lief, Panel-Rendering nicht, schwarzer Bildschirm. Vier GitHub-Issues gelesen, keine Lösung. Wechsel auf die Moddable-Toolchain, ESP-IDF 5.3.1 installiert, danach klassisches Python-Environment-Chaos zwischen venv, pyenv und pip-Rollbacks. Nach neun Stunden Abbruch, mit der Diagnose: ein offenes Issue im M5GFX-Repository blockiert den Weg.

Der pragmatische Workaround: Stock-Firmware plus eigener Server

Statt Custom Firmware: die Werksfirmware xiaozhi-esp32 behalten, aber die OTA-URL im NVS-Bereich (Non-Volatile Storage) per esptool und esp-idf-nvs-partition-gen umbiegen, sodass das Gerät bei meinem eigenen Server anklopft statt bei der Xiaozhi-Cloud. Als Server-Basis diente der Go-Fork rudyll/stackchan_ha_addons, erweitert um vier eigene Patches: ota_proxy.go für eine korrekte öffentliche WebSocket-URL, ein set_emotion-Tool für die Gemini Live API, eine Entity-Index-Erweiterung mit drei Fallback-Stufen für die Home-Assistant-Bereichszuweisung, und eine Memory-Persistenz-Schicht unter /data/vinci-memory.json. Deployment als Dockerfile-Resource in Coolify auf Hetzner, Cloudflare-Proxy statt Tunnel für die externe Erreichbarkeit.

Am 21. Mai lief VINCI end-to-end: Smart-Home-Steuerung, Sensorabfrage, Kalender, Wetter, dynamisches Emotion-Display, alles auf Österreichisch, nach einem chinesischen Wake-Word, weil die Stock-Firmware das nicht anders zulässt. Nur die Servos rührten sich nicht. Die Stock-Firmware koppelt Emotion-Frames ausschließlich ans Display.

Nachmittags-Update: Kamera, Push und Briefing

Noch am selben Tag kamen drei Erweiterungen dazu. Ein analyze_camera-Tool holt einen Snapshot über die Home-Assistant-Kameraproxy-Route, schickt ihn an die Gemini Vision API und liefert eine Beschreibung zurück, nur als Audio, weil die Stock-Firmware kein Bild aufs Display bringen kann. Der /vinci/push-Endpoint erlaubt proaktive Ansagen ohne Wake-Word, über Gemini TTS synthetisiert und per PCM-Stream ans Gerät geschickt. Der /vinci/briefing-Endpoint liefert ein Tagesbriefing auf Knopfdruck, mit paralleler Abfrage von Kalender, Wetter und Nachrichten. Eine Home-Assistant-Automation löst diesen Push fünfzehn Minuten vor jedem Kalendertermin aus.

Zwei Lektionen aus dieser Session, die ich seither immer wieder anwende: gemini-2.5-flash-native-audio-latest stürzt zuverlässig ab, sobald komplexe Multi-Step-Tools in der Live-Tool-Liste stehen, also gehören solche Tools als eigener HTTP-Endpoint implementiert, nicht in die Live-API. Und thinkingBudget: 0 muss bei der Text-API explizit gesetzt werden, sonst frisst das Modell seine gesamte Antwortlänge in internen Denk-Tokens auf.

Die Korrektur der Fehldiagnose

Im September bin ich aus Sturheit noch einmal an die Custom Firmware ran. Das M5GFX-Issue war längst beantwortet und spielte gar keine Rolle mehr. Der eigentliche Blocker war meine ESP-IDF-Version. xiaozhi-esp32 verlangt inzwischen zwingend 6.0.1 oder neuer, ich hatte 5.3.1 im Einsatz. Mit ESP-IDF 6.1 unter WSL Ubuntu lief der Build sofort durch, inklusive vollständiger CoreS3-Boarddefinition mit GC0308-Kamerasupport. Build-Kommando: python ./scripts/build.py m5stack/core-s3 --language de-DE --wake-word wn9_jarvis_tts.

Die Partitionstabelle des Geräts wurde per esptool read-flash 0x8000 0xc00 ausgelesen und byte-identisch nachgebaut, MD5-verifiziert, damit NVS bei 0x9000 unangetastet bleibt und WLAN-Zugangsdaten sowie die alte Servo-Kalibrierung jeden Flash überleben. Ergebnis: deutsches UI, Wake-Word Jarvis, 21 selbst gerenderte cyanfarbene Augen, dunkles Theme, Power-Save abgeschaltet, Kanal zum Server bleibt dauerhaft offen statt nur nach Wake-Word.

Dabei fiel auch ein monatelanger Bug: /vinci/push meldete regelmäßig „kein Gerät verbunden“, weil der interne Firmware-Timeout nur bei echten Datenframes zurückgesetzt wird, mein Server aber nur stille WebSocket-Pings schickte. Fix: alle 50 Sekunden zusätzlich ein JSON-Ping mitschicken, das die Firmware zwar ignoriert, aber als Datenframe zählt.

Code-Review mit Opus 5.5

Bevor ich mich an die Servos gewagt hab, hab ich das gesamte Projekt von Claude Opus 5.5 durchsehen lassen. Ergebnis: zwei Fehler in der Home-Assistant-Entity-Abfrage, die zu verstümmelter Sprachausgabe führten, bevor der Text überhaupt bei der Text-zu-Sprache-Strecke ankam. Genau die Art Fehler, die man beim x-ten Mal Drüberschauen selbst übersieht, weil man die Ursache am falschen Ende sucht.

Servo-Treiber und Gesichtsverfolgung

head_motion.h spricht direkt mit den zwei Feetech-Servos über UART1, 1 Mbaud, TX auf GPIO 6, RX auf GPIO 7, ID 1 für Yaw, ID 2 für Pitch, 0,3125 Grad pro Schritt, Servo-Strom über den PY32-IO-Expander via I²C. Jede Bewegung läuft über einen kritisch gedämpften Nachführer mit Tempolimit (25 °/s) und Beschleunigungsgrenze (80 °/s²), 20 Grad in etwa 1,7 Sekunden, kein Überschwingen.

face_tracker.h nutzt esp-dl mit human_face_detect, rund 2,5 Bilder pro Sekunde, das größte Gesicht steuert den Kopf. Vier Bugs hintereinander: invertiertes Pitch-Vorzeichen drückte den Kopf gegen den Anschlag, die 0-Grad-Ruhehaltung zeigte nur Tastatur und T-Shirt, das Kamerabild war seitenverkehrt, und die Standard-Erkennungsschwelle von 0,5 fand von Tischhöhe aus nur rund 7 Prozent der Bilder, mit 0,25 bis 0,3 waren es 81 Prozent, per A/B-Test direkt auf dem Gerät verifiziert.

Proaktives Sprechen hatte am Ende drei getrennte Ursachen: die Firmware öffnete den Kanal nur beim Wake-Word, ein ungepinnter git clone main im Dockerfile zog stillschweigend einen Upstream-Bug mit, der den Audio-Stream stumm hielt, und der Home-Assistant-Timeout von 10 Sekunden war zu kurz für Formulierung plus Synthese.

Aktueller Stand und offene Baustellen

Der Kopf bewegt sich, folgt meinem Gesicht, sucht mich, wenn ich den Raum verlasse, legt sich nach vier Sekunden ohne Treffer schlafen. Vinci meldet sich proaktiv bei Kalenderterminen, begrüßt mich im Büro, und ein Gespräch endet jetzt nach 20 Sekunden ohne Antwort, statt endlos zuzuhören.

Offen bleiben sporadische Neustarts nach Server-Redeploys, eine Diagnose-Firmware läuft mit. set_emotion wird vom Modell trotz explizitem Prompt-Hinweis nie aufgerufen, Emotionen kommen aktuell nur aus speakPCM und der zeitabhängigen idleMood(). Uhrzeiten werden von Gemini gelegentlich falsch ausgesprochen.

Firmware als Patch gegen xiaozhi-esp32, Server-Dockerfile und Home-Assistant-Beispiele liegen offen auf GitHub: github.com/7H3-CH053N/StackChan-CustomFW

Mein KI-Kennzeichnung Tool setzt sichtbare EU-Icons oder ein Textlabel in Bilder, wie es Artikel 50 Absatz 4 der KI-Verordnung für veröffentlichte KI-Inhalte verlangt. Mein Dreh: echte EU-Icons der Kommission statt nachgebauter Grafiken, Stapelverarbeitung und eine zweisprachige Seite, die auf die digitalhandwerk-Entität einzahlt. Zielort ist watermark.digitalhandwerk.rocks, gebaut komplett clientseitig mit Canvas-API, ohne Server, ohne Upload, ohne Build-Prozess. Ein FTP-Ordner reicht.

Was die Seite technisch ist

Kein Framework, kein npm, kein Build-Schritt. Der Ordner enthält index.html für die deutsche Fassung, en/index.html für die englische mit eigenem Schema, icons.js mit den sechs offiziellen EU-SVGs als base64-Data-URIs, einen lokal gehosteten fonts/-Ordner mit Inter Tight, DM Mono und Fraunces Italic, dazu Wortmarke, Autorenbild und Social-Vorschau als einzelne Bilddateien. .htaccess, robots.txt, sitemap.xml und llms.txt regeln Sicherheit und Crawling.

CSS und JavaScript sind in beiden Sprachfassungen zeichengleich, nur Pfade und eine Anker-ID unterscheiden sich. Ein Diff-Skript prüft das nach jeder Änderung, sonst laufen die zwei Dateien mit der Zeit auseinander, und genau das ist einmal passiert, dazu gleich mehr.

Funktionsumfang

Entweder EU-Icon oder Textlabel, nie beides. Doppelt gekennzeichnet ist nicht klarer, nur voller. Drei Icon-Varianten stehen zur Wahl: vollständig KI-generiert, teilweise bearbeitet, KI war beteiligt. Position lässt sich auf vier Ecken setzen, Labelfarbe hell oder dunkel, Hintergrund dunkel, hell oder ganz ohne, Größe zwischen 2 und 15 Prozent der Bildbreite, dazu Deckkraft. Export geht als PNG, JPEG oder WebP.

Die Stapelverarbeitung erlaubt mehrere Bilder auf einmal, mit Vorschau-Auswahl per Dateiname, alle mit denselben Einstellungen. Der Download läuft als sequenzielle Einzeldateien mit 300 ms Pause dazwischen, kein ZIP. Ein Store-ZIP wäre rund 40 Zeilen selbstgeschriebenes Binärformat oder eine zusätzliche Dependency gewesen, der Aufwand stand bei kleinen Stapeln nicht im Verhältnis zum Nutzen.

Maschinenlesbare Herkunft: IPTC DigitalSourceType

Das sichtbare Label ist die eine Hälfte, die andere ist IPTC DigitalSourceType als XMP direkt in der Bilddatei. Der Wert folgt der Icon-Wahl: vollständig KI-generiert wird zu trainedAlgorithmicMedia, teilweise bearbeitet zu compositeWithTrainedAlgorithmicMedia, KI beteiligt zu compositeSynthetic. Alle drei Werte sind überschreibbar, WebP kann das Tool nicht, das zeigt die UI sichtbar an.

Technisch passiert das nach dem Canvas-Export direkt im Byte-Container: bei JPEG als APP1-Segment hinter dem JFIF-Block, bei PNG als iTXt-Chunk hinter dem IHDR mit selbst gerechnetem CRC32. Rund 90 Zeilen, keine Bibliothek. Verifiziert habe ich das mit Pillow gegen die echten Browser-Bytes, nicht gegen meinen eigenen Code, sonst prüft man nur, ob der eigene Fehler konsistent ist.

Und dabei bin ich auch auf den unangenehmsten Bug der ganzen Entwicklung gestoßen: Die JPEG-Segmentlänge zählt sich selbst mit, ein Segment endet bei 4 + len, nicht bei 4 + len - 2. In einer früheren Fassung war der Abzug drin und hat das XMP mitten in den JFIF-Block geschrieben. Die Datei blieb lesbar, kein Tool fand aber die Metadaten. Genau dieser Bug wäre ohne den Pillow-Abgleich gegen echte Browser-Bytes durchgerutscht, weil die Datei ja funktionierte, nur eben ohne den Inhalt, den sie tragen sollte.

Die inhaltliche Präzisierung, die den Unterschied macht

Das Tool bedient bewusst nur Artikel 50 Absatz 4, die Offenlegungspflicht für Betreiber, die KI-Inhalte veröffentlichen. Dafür reicht eine klare, wahrnehmbare Kennzeichnung. Absatz 2 betrifft Anbieter von KI-Systemen und verlangt eine maschinenlesbare Markierung, etwa über C2PA Content Credentials, ein sichtbares Label erfüllt das ausdrücklich nicht. Die meisten Zusammenfassungen im Netz werfen beide Absätze zusammen, genau diese Unterscheidung ist der inhaltliche Kern der Seite.

Dazu die Klarstellung, dass Absatz 4 auf Deepfakes zielt, nicht auf jedes KI-Bild. Eine abstrakte KI-Textur fällt nicht darunter, eine KI-Person, die wie ein Teamfoto aussieht, schon.

Wie das IPTC-Feld in der Praxis ankommt

Im IPTC-Test vom März 2026 werteten Instagram und Pinterest das Feld aus, LinkedIn liest stattdessen C2PA, TikTok und YouTube erkannten nichts. Geprüft wurde dabei Material aus Metas eigenem Generator, ob ein nachträglich gesetztes Feld genauso behandelt wird, sagt der Test nicht. Meine erste eigene Beobachtung: Instagram labelt nicht automatisch, dort greift nur der manuelle Schalter.

Wichtig: Das Feld ist keine C2PA-Signatur und belegt keine Herkunftskette, es erfüllt die Anbieterpflicht aus Absatz 2 nicht, es ist eine Angabe des Veröffentlichenden. Wer den falschen Wert wählt, hinterlegt eine falsche Aussage in maschinenlesbarer Form. Und die Zuordnung ist eine Falle: compositeWithTrainedAlgorithmicMedia heißt laut IPTC „Edited using Generative AI“, also mit KI bearbeitet, nicht „KI-Teile kombiniert“. Dafür gibt es compositeSynthetic, der Name legt das Gegenteil nahe.

Technische Grundentscheidungen

Canvas-API, keine Dependency. Bild rein, Label drauf, toBlob raus. Nichts verlässt den Rechner, das ist das Verkaufsargument gegenüber jedem serverbasierten Tool.

Icons als base64 in icons.js. Aus dem offiziellen SVG-ZIP der Kommission gezogen, nicht nachgebaut. width und height sind aus der viewBox eingesetzt, sonst rastert Firefox auf 300×150.

Fonts lokal, kopiert aus dem Elementor-Font-Ordner der Hauptseite. Kein Google-CDN, DSGVO-sauber und optisch identisch.

FAQ als natives <details>, kein Accordion-JavaScript.

Matomo (self hosted), gleiche SiteId für beide Sprachen, mit disableCookies vor trackPageView. Nachgemessen: keine _pk_-Cookies.

Ein echter Sicherheitsfund

Dateinamen gingen per innerHTML in die Vorschau-Liste. Ein Name wie <img onerror=…>.png hätte Code ausgeführt, Self-XSS, von außen nicht auslösbar, aber real. Behoben über createElement plus textContent, gegengetestet.

Die .htaccess setzt Verzeichnisauflistung aus, nosniff, frame-ancestors nur für eigene Domains, Referrer- und Permissions-Policy sowie Caching. Vor der Domain steht Cloudflare, läuft der Origin unter nginx, wird die Datei ignoriert und die Header müssen in die Serverkonfiguration.

Crawling ist ausdrücklich erwünscht: robots.txt erlaubt alles und listet GPTBot, ClaudeBot, PerplexityBot, Google-Extended und weitere einzeln auf, sitemap.xml deckt beide Sprachen mit hreflang ab, llms.txt fasst die fachlichen Kernaussagen maschinenlesbar zusammen.

SEO und E-E-A-T

Zwei echte URLs statt JS-Umschaltung, verbunden über hreflang de/en/x-default in beide Richtungen und im Schema über workTranslation/translationOfWork. Das JSON-LD nutzt für Person und LocalBusiness dieselben @id-Werte wie die Hauptseite, damit Google und LLMs die Entität konsolidieren, dazu eine sichtbare Autorenbox, weil Schema ohne sichtbaren Beleg wenig trägt.

FAQ-Rich-Results hat Google am 07.05.2026 abgeschaltet, das FAQPage-Markup bleibt gültig und schadet nicht, sein Wert liegt heute bei AI Overviews und LLM-Crawlern, nicht mehr im SERP-Snippet.

Bewusst nicht gebaut: Video

Am 25.08.2026 geprüft und verworfen. WebCodecs bräuchte eigenes MP4-Muxing und läuft nicht auf Firefox Android, ffmpeg.wasm hat ein hartes 2-GB-Limit und kann auf iOS Safari schon bei 200 MB abstürzen. Für 4K-Kundenvideos müsste die Verarbeitung auf einen Server, und damit wäre das „kein Upload“-Versprechen weg. Der Aufwand stand nicht im Verhältnis.

Was mich beim Bauen erwischt hat

Ein paar Fehler, an denen ich länger hing als geplant, für alle, die Ähnliches vorhaben:

• Die drei EU-Icons haben unterschiedliche Seitenverhältnisse, 1:1, 3,16:1, 3:1. Quadratisch gezeichnet werden zwei davon gequetscht. Breite immer aus naturalWidth/naturalHeight ableiten, nicht aus einem fixen Wert.
• clamp() ohne Leerzeichen um das Plus, 1.4rem+2.4vw statt 1.4rem + 2.4vw, ist ungültiges CSS und reißt die gesamte font-Shorthand mit. Die Headline fällt still auf die geerbte Schrift zurück, ohne Fehlermeldung im Browser.
• Beim Übersetzen wurden nur die HTML-Texte erfasst. Die UI-Strings im JavaScript blieben deutsch, die englische Seite zeigte „2 Bilder herunterladen“. Die Lösung war eine kleine Textkonstante mit beiden Sprachen, gesteuert über <html lang>, damit das Skript in beiden Dateien identisch bleibt.
• Media Queries lassen sich nicht testen, indem man die Breite eines Elements per DevTools ändert. Sie hängen am echten Viewport. Ein ganzer Messdurchlauf war dadurch wertlos, bevor ich das gemerkt habe.
• Emoji-Flaggen rendern unter Windows nicht als Flagge, sondern als Buchstabenpaar. Der Sprachwechsler nutzt deshalb Inline-SVG, zusammen unter 600 Byte.
• Python schreibt im Textmodus unter Windows CRLF. Ein einziger Python-Edit stellte alle Zeilenenden der englischen Datei um und brach den Diff-Check zwischen den Sprachfassungen.

Was noch fehlt

Bei Hintergrund „ohne“ gibt es keinen Schatten hinter Icon oder Text, auf unruhigen Motiven kann das Label untergehen, ein weicher Schatten wären drei Zeilen. Ein ZIP-Download für größere Stapel steht noch aus, falls die Einzeldateien im Alltag nerven. WebP-Metadaten fehlen ebenfalls, dafür müsste der RIFF-Container auf VP8X umgebaut werden, falls das Format im Alltag wichtiger wird als jetzt.

Downloads: github.com/7H3-CH053N/Magma/releases

Der Dokumente-Ordner fragt jetzt nur noch einmal

Die zwei Klicks beim ersten Start waren erklärbar, das stand seit v0.1.0 so in den Release Notes. Teurer war etwas anderes, und das habe ich vorher unterschätzt: macOS bindet erteilte Berechtigungen an die Identität einer App. Ohne Signatur hat Magma keine stabile Identität. Also sah jeder Start wie eine neue App aus, und die Systemabfrage für den Dokumente-Ordner kam wieder. Bei einer Notiz-App, deren Vault genau dort liegt, ist das kein Schönheitsfehler, sondern ein Dialog zwischen mir und meiner Arbeit, jeden einzelnen Tag.

Mit Signatur fragt macOS einmal.

Alles bis einschließlich v0.1.5 bleibt unsigniert. Ich baue keine alten Tags neu.

Sechs Secrets, alle optional

Gesteuert wird das Signieren ausschließlich über sechs Repository-Secrets:

Alle sechs sind optional, genau wie der Updater-Schlüssel. Ist keines gesetzt, entsteht trotzdem ein installierbares DMG, eben das unsignierte. Ein Fork braucht davon nichts, und niemand muss ein Apple-Konto haben, um Magma selbst zu bauen. Das war mir wichtiger als ein schlanker Workflow: Ein Repo, das ohne meine Zertifikate nicht mehr baut, ist kein offenes Repo.

Die Variablennamen sind Tauris eigene. Ich habe sie aus der macOS-CLI-Binary der gepinnten Version gezogen, per npm pack und strings, statt sie aus dem Gedächtnis zu schreiben. hardened_runtime steht in tauri-utils 2.9.3 ohnehin auf true, da war nichts zu tun.

Drei Stolpersteine, die in keiner Anleitung stehen

Die .p12 muss aus „Meine Zertifikate“ in der Schlüsselbundverwaltung exportiert werden. Nur unter diesem Punkt hängt der private Schlüssel mit dran. Der Export aus der Ansicht „Zertifikate“ ergibt eine Datei, die aussieht wie eine .p12, sich importieren lässt und nichts signiert.

security find-identity -v -p codesigning meldete zweimal 0 valid identities found, bei sichtbar installiertem Zertifikat, aus zwei verschiedenen Gründen nacheinander. Erst lag das Zertifikat im System-Schlüsselbund und der private Schlüssel in Anmeldung. Beide müssen im selben liegen. Danach fehlte Apples Zwischenzertifikat Developer ID – G2, das man sich bei apple.com/certificateauthority holt. Ohne das lässt sich die Kette nicht prüfen, und die Identity gilt als ungültig. Ohne installiertes Xcode ist es oft nicht da. Der Befehl, der die beiden Fälle trennt, ist security find-identity ohne -v: Dort taucht die Identity dann mit CSSMERR_TP_NOT_TRUSTED auf, statt einfach zu fehlen.

Für die Notarisierung reicht ein App-Store-Connect-Teamschlüssel mit der Rolle „Entwickler“. App Manager braucht es nicht. Die .p8 lässt sich genau einmal herunterladen, danach ist sie weg.

Zwei Zeilen im Workflow, die je eine Debug-Runde gekostet haben

Die Variablen gehen über GITHUB_ENV, nicht über das env: des Schritts. Mit env: wird ein fehlendes Secret zur leeren Zeichenkette, und ein leeres APPLE_CERTIFICATE lässt die CLI mit nichts signieren wollen. Das ist exakt die Fehlerform, die mir der fehlende Updater-Schlüssel schon einmal beschert hat: nicht „Secret fehlt“, sondern ein Signaturfehler mitten im Build. Über GITHUB_ENV bedeutet ein fehlendes Secret eine fehlende Variable, und Tauri überspringt das Signieren.

Das Zertifikat wird per Heredoc geschrieben. Eine base64-kodierte .p12 kann Zeilenumbrüche enthalten, und eine KEY=value-Zeile in GITHUB_ENV schneidet am ersten davon ab. Der Notarisierungsschlüssel landet in einer Datei, weil Tauri einen Pfad erwartet, ein Secret aber nur Inhalt halten kann.

36 Minuten in Apples Warteschlange

Der erste Lauf brauchte 36 Minuten zwischen „Notarizing“ und „Finished with status Accepted“. Derselbe Job unsigniert: acht. Das ist kein Fehler, das ist Apples Queue, und man sieht währenddessen nichts, weil GitHub die Logs eines laufenden Jobs nicht herausgibt (HTTP 404).

Ein brauchbarer Zwischenbeweis von außen: In App Store Connect unter Benutzer und Zugriff → Integrationen zeigt der Schlüssel ein „Zuletzt verwendet“. Steht dort das heutige Datum, ist die Einreichung angekommen und man wartet nur noch.

Der bundle-Job hatte kein Zeitlimit, also galt GitHubs Standard von sechs Stunden. Auf einem macOS-Runner, der zehnfach abgerechnet wird. Steht jetzt auf timeout-minutes: 60. Ein Release dauert damit rund 45 Minuten statt acht, und das ist der Preis, den ich ab jetzt bei jeder Version zahle.

Windows bleibt unsigniert

Die MSI baue ich weiter mit, jede Version, und ich teste sie auch. Aber SmartScreen meldet sich dort weiterhin mit „Weitere Informationen → Trotzdem ausführen“. Ein Windows-Code-Signing-Zertifikat ist ein eigenes Produkt, separat gekauft und jährlich verlängert. Für ein Nebenprojekt, das ich selbst auf dem Mac benutze, gebe ich das Geld nicht doppelt aus. Der Fokus liegt auf Apple.

Und dann waren da noch die Bugs

Die Farbwahl im Graph wurde nie exakt übernommen. Helles Rot wurde volles Rot, Grau wurde Rot. Schuld war eine Funktion: hueFromHex behielt den Farbton und warf Sättigung und Helligkeit weg, alles danach baute sich auf festen 66 % und 56 % neu auf. Grau ist der schlimmste Fall, weil es gar keinen Farbton hat, also griff if (d === 0) return 0. Und 0 ist Rot. Der Picker selbst war nie falsch, er liest den gespeicherten Hex direkt. Nur die Zeichenfläche widersprach ihm, was die Meldung „die Farbe wird nicht übernommen“ erklärt statt „das Bedienelement ist kaputt“. Die Arithmetik liegt jetzt in src/lib/graphColors.ts und ist ohne DOM testbar.

Meine eigene Regression, zweimal falsch gelöst. Die Unterordner-Schattierung, die ich mit dem Farbfix eingebaut hatte, kollabierte. Ein Fächer, der pro Schritt breiter wurde und an der Bandgrenze klemmte, legte jeden Schritt ab dem vierten auf eine der beiden Kanten. Ein Ordner mit zwölf Unterordnern kam als zwei flache Blöcke heraus. Der zweite Versuch scheiterte anders: Eine symmetrische Leiter ist bei halber Bandbreite kongruent, also landeten Schritt 5 und 6 auf demselben Wert. Beide Versuche bestanden einen Test, der nur die ersten vier Schritte ansah. Ein Test mit zu kleinem N ist ein Freispruch, den man sich selbst ausstellt.

Geisterknoten in der Legende, mit Einträgen wie missing:[ai.rs](http:. Link-Ziele ohne Notiz dahinter tragen eine synthetische ID statt eines Pfades, und wenn das Ziel selbst ein Markdown-Link ist, steckt darin eine URL. Die Ordner-Erkennung las den Schrägstrich in http:// als Ordnergrenze. Gefiltert wird jetzt über das missing-Flag, nicht durch Schnüffeln am String.

Farbschemata gibt es jetzt pro Modus, sieben Tokens für hell und sieben für dunkel, beide gleichzeitig sichtbar statt dem aktuellen Modus folgend. Einen dunklen Akzent zu bearbeiten, während man das helle Schema ansieht, ist der Normalfall. Dazu eine Kontrastwarnung nach WCAG 2.1, AA für normalen Text. Geprüft wird nur Text gegen seinen Hintergrund. Akzentfarbe und die KI-Markierung sind bewusst ausgenommen, weil sie Marker und Button-Füllungen sind: Am Fließtext-Maßstab gemessen würden schon die ausgelieferten Standardwerte durchfallen, und eine Warnung, die auf einer unveränderten Installation feuert, bringt Leuten bei, Warnungen zu ignorieren.

Der Blog-Import blieb fünf Minuten auf „593 Beiträge gefunden“ stehen. Er lief, und der Großteil der Arbeit war sinnlos: Der RSS-Rückfall geht bis zu dreißig Feed-Seiten einzeln durch, um Autorennamen zu finden, die die REST-API nicht liefert. Er lief vor dem Anwenden des eingetragenen Autors, also wurde jeder gefundene Name eine Zeile später überschrieben. Der Autor wird jetzt vorher gelesen und durchgereicht, bei gesetztem Autor fasse ich den Feed gar nicht mehr an. Ein Test pinnt die Reihenfolge, weil genau so etwas ein Refactor wieder einbaut, ohne dass irgendwas fehlschlägt.

Der erste Frontend-Test überhaupt

36 Vitest-Tests in graphColors.test.ts, theme.test.ts und contrast.test.ts. npm test existierte vorher als Skript, das nie jemand aufrief, auch die CI nicht. Ein Frontend-Test hätte also geschrieben und still nie ausgeführt werden können. Das ist das Hausmuster dieses Projekts in Reinform: Die gefährlichen Fehler in Magma waren durchweg solche, die nichts kaputt machen, was ein gewöhnlicher Test bemerkt. Der checks-Job ruft npm test jetzt auf.

Zwei meiner eigenen Kontrast-Tests behaupteten übrigens das Gegenteil dessen, was die Arithmetik tut. Ich habe nachgemessen, statt sie anzupassen, bis sie grün waren.

Was offen bleibt

Das Auto-Update ist eingebaut, aber nicht scharf. Es hängt am Minisign-Schlüssel, den nur ich als Repo-Inhaber erzeugen kann, und der ausgelieferte pubkey ist noch ein Platzhalter. Tauris Updater-Schlüssel hat mit dem Apple-Zertifikat nichts zu tun, das ist ein eigenes Paar, kostenlos und selbst erzeugt. Ich hatte das lange falsch im Kopf und beides in einen Topf geworfen.

Und Issue #18 steht weiter: kein Index, kein Watcher, die Oberfläche pollt alle vier Sekunden. Gemessen an 8000 Notizen liest list_notes kalt 705 ms. Spürbar, aber kein Fehler. Der In-Memory-Index kommt, wenn ich die lokalen Embeddings angehe, denn ohne ihn haben sie keine Grundlage.

Vier Releases später, gestern kam v0.1.3, ist daraus ein Projekt geworden, an dem jemand mitarbeitet, den ich nie getroffen habe, und in dem ein Fremder ein Problem gefunden hat, das ich selbst nie bemerkt hätte.

Das ist der Teil an einem Devblog, den ich nicht weglassen will. Ein Changelog zeigt, was funktioniert. Ein Devblog zeigt, was ich übersehen habe, bis mich jemand daraufgestoßen hat.

Hier ist der Stand heute: was Magma überhaupt ist, was in v0.1.3 steckt, welches Problem im MCP-Server aufgetaucht ist, und woran ich gerade tatsächlich schraube.

Was ist Magma?

Magma ist eine Notiz-App für macOS und Windows. Open Source unter MIT-Lizenz, kein Account, kein Abo, keine Telemetrie.

Die Grundidee kennst du, wenn du Obsidian kennst: Deine Notizen sind ganz normale Markdown-Dateien in einem Ordner auf deiner Platte. Du verbindest sie mit [[wikilinks]], siehst zu jeder Notiz die Rückverweise, und ein Graph zeigt dir, wie dein Wissen zusammenhängt. Wenn du Magma morgen löschst, bleiben deine Dateien liegen und lassen sich mit jedem Texteditor weiterbearbeiten. Einen bestehenden Obsidian-Vault öffnest du direkt, ohne Import.

Der Unterschied steckt im zweiten Autor. Magma bringt einen MCP-Server mit, über den Claude deinen Vault lesen und beschreiben kann. Nicht als Chatfenster am Rand, sondern als Schreibzugriff auf dieselben Dateien, in denen du selbst arbeitest. MCP ist kurz gesagt ein Protokoll, über das ein Sprachmodell Werkzeuge auf deinem Rechner benutzen darf. In diesem Fall Werkzeuge, die deine Notizen suchen, lesen, anlegen und verknüpfen.

Genau das ist der Punkt, an dem die meisten zurecht misstrauisch werden. Deshalb prüft Magma jeden [[link]], den ein Modell schreiben will, gegen den echten Bestand, statt tote Verweise entstehen zu lassen. KI-geschriebene Notizen bekommen author: ai in die Frontmatter, erscheinen violett im Graph und stehen gesammelt auf einer eigenen Seite. Vor jedem KI-Schreibzugriff sichert Magma einen Versionsstand.

Was steckt in v0.1.3?

Zwei Dinge, beide in Pull Request 19.

Schnappschuss vor jedem KI-Schreibzugriff. Bisher hat Magma vor größeren Änderungen und vor jedem vaultweiten Ersetzen eine Version gesichert. Jetzt greift dieselbe Mechanik, sobald Claude über den MCP-Server schreibt, egal wie klein der Eingriff ist. Der Gedanke dahinter ist simpel: Ich merke sofort, wenn ich selbst etwas kaputt mache. Bei einem Modell merke ich es unter Umständen erst drei Tage später, wenn ich die Notiz wieder aufmache. Dann brauche ich einen Stand von vorher, nicht eine Erklärung.

Umlaute in Notiznamen. Notizen wie Bürokratie.md oder Übersicht Projekte.md haben sich in v0.1.2 nicht sauber verhalten. In einer App, die ein deutschsprachiger Entwickler für den eigenen deutschsprachigen Vault gebaut hat. Behoben. Den technischen Hergang lasse ich hier bewusst offen, weil ich ihn ohne den Commit vor mir nicht sauber wiedergeben kann, und einen halb erinnerten Bugfix nachzuerzählen bringt niemandem etwas.

Was mich daran mehr beschäftigt als der Bug selbst: Meine eigenen Testnotizen tragen fast alle englische Titel, weil der Code englisch ist und ich beim Entwickeln in dem Kontext bleibe. Der Fehler saß in der Lücke zwischen der Sprache, in der ich baue, und der Sprache, in der ich schreibe.

Warum mir ein fremdes Issue mehr bringt als sieben Stars

Am 7. August hat bo-developing Issue 18 aufgemacht. Titel, sinngemäß: Es gibt keinen Vault-Index, jeder MCP-Schreibvorgang kostet ungefähr drei komplette Vault-Durchläufe. Frage dahinter: Wie verhält sich das bei mehreren tausend Notizen?

Die ehrliche Antwort ist, dass ich es nicht weiß. Mein Vault ist ein persönlicher Vault. Der Graph baut sich in Millisekunden auf, die Suche fühlt sich sofort an, find_link_candidates liefert ohne spürbare Wartezeit. Bei meiner Größenordnung fällt ein linearer Durchlauf schlicht nicht auf.

Das ist der klassische Blindfleck beim Bauen für sich selbst. Ich habe die Vault-Logik in magma-core gekapselt und unit-getestet, damit Desktop-App und MCP-Server garantiert dasselbe Modell meiner Notizen sehen. Über das Laufzeitverhalten sagt diese Architektur nichts. Sauber getrennt und trotzdem dreimal zu viel gelesen, das schließt sich nicht aus.

Was mir das Issue konkret gebracht hat: eine Messgröße, die ich vorher nicht hatte, und die Erkenntnis, dass ich einen synthetischen Vault mit ein paar tausend Notizen brauche, bevor ich irgendetwas optimiere. Erst messen, dann cachen. Ein Index, den ich baue, ohne die Kosten zu kennen, ist nur eine zweite Datenquelle, die falsch werden kann.

Sieben Stars sind nett. Ein Issue, das eine Annahme in meinem Kopf zerlegt, ist unbezahlbar.

Woran ich gerade arbeite

Drei offene Pull Requests, Stand jetzt.

alexandermut hat in Nummer 15 einen In-App-Updater beigesteuert. Er hat schon in v0.1.2 den Großteil der eingegangenen Änderungen geliefert, was die Beschreibung „Ein-Personen-Projekt“ inzwischen ungenau macht. Ich habe seinen Stand in Nummer 21 auf v0.1.3 rebased, weil der Unterbau sich seither bewegt hat und ich ihm keinen Merge-Konflikt zumuten will, den ich selbst verursacht habe.

Nummer 22 ist mein eigener Entwurf für den Remote-Vault: Ordner einzeln durchgehen, statt den kompletten Baum in einem Rutsch beim WebDAV-Server anzufragen. Auf einem lokalen Testserver ist der Unterschied kaum messbar. Auf einer echten Verbindung mit Latenz und Timeouts ist es der Unterschied zwischen „Sync läuft“ und „Sync hängt“.

Dazu Issue 20, das ich heute selbst geöffnet habe: Ein Vault soll seine eigenen Schreibkonventionen tragen und sie dem Modell mitgeben können. Ordnerstruktur, Namensschema, Frontmatter-Felder, Sprache. Aktuell schreibt Claude in meinem Vault ordentlich, weil ich es ihm in jedem Chat neu sage. Das ist keine Lösung, das ist eine Gewohnheit. Die Regeln gehören in den Vault, nicht in meinen Kurzzeitspeicher.

Was offen ist und mich stört

Die Installer sind nach wie vor nicht signiert. macOS meldet einen unbekannten Entwickler, Windows wirft SmartScreen. Beides mit zwei Klicks zu umgehen, beides trotzdem eine Hürde, die genau die Leute abschreckt, denen ich Datenkontrolle verspreche. Code Signing steht in Meilenstein M5 offen. Auto-Update hängt daran mit dran, weil ein Updater ohne Signatur nur den nächsten unsignierten Build nachlädt.

Das WebDAV-Passwort lebt in der Session. Nach dem Neustart wieder eintippen. Speicherung im Schlüsselbund des Betriebssystems ist geplant, nicht gebaut.

Ähnliche Notizen sind lexikalisch, nicht semantisch. TF-IDF über den Vault, verglichen per Kosinus. Das findet Notizen mit denselben Wörtern, nicht Notizen mit derselben Bedeutung. Ich nenne das im README bewusst so, weil der Unterschied bei einer Funktion namens „ähnliche Notizen“ nicht in die Fußnote gehört. Der Vorteil: kein Modell-Download, keine Laufzeit, kein Netz.

Was du tun kannst

Magma läuft auf macOS als Universal Binary und auf Windows 10 und 11 in 64 Bit. Die Installer liegen bei den Releases auf GitHub, dazu die Anleitung, wie du an der Warnung des Betriebssystems vorbeikommst. Magma legt in deinem Ordner nur ein verstecktes .magma-Verzeichnis für den Versionsverlauf an und schreibt sonst nichts Proprietäres in deine Dateien.

Wer Claude erst einmal nur schauen lassen will, setzt MAGMA_MCP_ALLOW_WRITE=0. Dann liest der MCP-Server den Vault, schreibt aber nichts. Ich empfehle das für die erste Sitzung ausdrücklich, weil du dabei siehst, wie das Modell durch deine Verlinkungen navigiert, ohne dass etwas in deinen Dateien landet. Wenn du danach umschaltest, ist die Seite „Was Claude geschrieben hat“ dein Kontrollpunkt: Sie listet jede Notiz mit author: ai in der Frontmatter, die neueste zuerst.

Wenn du einen Vault mit mehreren tausend Notizen hast, bist du gerade die interessanteste Testperson, die ich haben kann. Zeig mir, wo es hakt. Wenn dir ein Bug auffällt, lies vorher kurz die offenen Issues, vielleicht steht er schon drin.

Ich baue kein Produkt, das fertig sein will. Ich baue ein Werkzeug, das ich täglich benutze und öffentlich repariere. Das nächste Stück Arbeit ist der synthetische Vault, mit dem ich Issue 18 endlich nachmessen kann.

Das ist mein Dev-Log dazu. Nicht Handbuch, nicht Tutorial. Nur die ehrliche Geschichte, wie ein Nachmittag Spieltrieb in eine fertige .exe mit eigenem Installer mündet.

Wie kommt man auf so eine Idee?

„Ich brauche das nicht.“ Das war mein erster Gedanke, als ich das Claude-Code-Maskottchen zum ersten Mal in Aktion gesehen habe: dieser kleine terracotta Roboter, der auf Bildschirmen herumläuft. Zweiter Gedanke, fünf Minuten später: „Ich will das auf meinem Desktop haben.“

Das ist eigentlich die ehrlichste Erklärung für ungefähr die Hälfte meiner Projekte.

Clawd, der originale, stammt von Anthropic. Das war mein Ausgangspunkt fürs Konzept. Ich wollte einen Desktop-Begleiter, der still existiert, hin und wieder eine Aktion spielt, auf Klick eine App startet, und sonst aus dem Weg ist. Genau wie der gute alte Clippy, nur dass niemand ihn aktiv gebeten hat, dir beim Schreiben zu helfen. Clawd hilft nicht. Clawd ist einfach da. Das ist, wenn man es genau nimmt, seine größte Qualität.

Wo das Projekt technisch begann

Der Plan war nicht komplex. Python, weil ich das aus VINCI kenne, tkinter für ein rahmenloses Overlay-Fenster, Pillow für die Bildverarbeitung. Fertig.

Was ich noch nicht hatte: die eigentlichen Animationen. Und hier wurde es interessant.

Ich hätte einfach fremde Assets verwenden können. Tue ich aber grundsätzlich nicht, wenn Lizenzfragen auch nur im Entferntesten unklar sind. Also habe ich selbst Hand angelegt: Ich habe die Animationszustände als SVG-Dateien gebaut. Jede Figur-Pose, jeder Zustand, von Idle über Reading bis Headphones-Groove, erst als skalierbare Vektorgrafik konstruiert. Clawd als Baukasten, Schicht für Schicht. Das hat länger gedauert als der Code selbst, aber es ist meins, es ist sauber, und ich kann ihm jederzeit ein neues Tanzprogramm geben.

Den animierten Teil, also die tatsächlichen Frame-Sequenzen aus den SVGs, hat dann Claude übernommen. Ich habe die Strukturen geliefert, Claude hat daraus lebende Animationen gemacht. So funktioniert Vibe Coding für mich seit Monaten: Ich bringe das Konzept und die Ausgangsmaterialien, die KI macht aus den Rohformen etwas, das sich bewegt. Das ist keine Abkürzung. Das ist Arbeitsteilung.

Was Clawd technisch unter der Haube treibt

Das technische Herzstück ist überschaubar und sauber gehalten, was bei Python-Projekten nicht selbstverständlich ist.

tkinter liefert das Fenster: rahmenlos, transparent per Magenta-Key (#FF00FF), topmost oder normal je nach Einstellung. Transparente Pixel sind automatisch durchklickbar, Clawd „liegt“ also wirklich auf dem Desktop ohne die Arbeit darunter zu blockieren.

Pillow verarbeitet die Animation: Alle Zustände teilen eine gemeinsame Frame-Box, die COMMON_BOX, die als Vereinigung aller Inhalts-Bereiche definiert ist. Dadurch springt Clawd beim Zustandswechsel nicht, er bleibt an Ort und Stelle. Jeder Frame wird auf Nearest-Neighbor skaliert, kein Weichzeichnen, kein Halo-Effekt, der Pixel-Stil bleibt erhalten.

Die State-Machine ist simpel: Idle-Loop als Grundzustand, alle paar Sekunden ein zufälliger Wechsel in eine Aktion, danach zurück zu Idle. Intervall und Aktionspool sind frei konfigurierbar.

Mausbedienung: Ziehen verschiebt Clawd, die Position wird sofort in der config.json gespeichert. Einfacher Klick ohne Drag startet das eingestellte Programm. Rechtsklick öffnet ein Menü mit Einstellungen und Beenden.

Die Sprechblasen waren die lustigste Erweiterung. Ein separates transparentes Toplevel-Fenster erscheint knapp über Clawds Kopf: Mono-Schrift, eckiger terracotta Rahmen mit Pixel-Ecken, automatisches Ausblenden nach ein paar Sekunden. Texte sind frei konfigurierbar, und seit der letzten Ausbaustufe auch kontextabhängig: Clawd kennt die Uhrzeit, erinnert mich nach einer Stunde ununterbrochener Arbeit an eine Pause, warnt mich wenn der Akku unter 20 Prozent fällt, und holt sich auf Wunsch das aktuelle Wetter via OpenWeatherMap.

Dass ein Pixel-Mascottchen mich an meine Kaffeepause erinnert, hätte mir noch vor zwei Jahren seltsam vorgekommen. Jetzt finde ich es eigentlich sinnvoller als jeder Kalender-Alarm.

Warum die Build-Kette genauso wichtig war wie der Code

Ein Python-Script ist kein Produkt. Das weiß jeder, der versucht hat, einem anderen Menschen ein Python-Script zu geben. Also musste aus clawd.py eine echte Anwendung werden.

PyInstaller macht daraus eine Clawd.exe: Single-File, kein Python erforderlich, kein Terminalfenster. Etwa 18 MB. Das klingt groß für einen Desktop-Begleiter, ist aber der Preis für eine portable, unabhängige Anwendung.

Inno Setup baut daraus einen echten Windows-Installer. Kein Admin erforderlich, weil der Zielpfad %LOCALAPPDATA%\Programs\Clawd ist. Der Installer fragt beim Setup nach Autostart (vorausgewählt, weil das der Sinn der Sache ist) und nach einer optionalen Desktop-Verknüpfung. Clawd erscheint danach unter Windows „Apps“ als reguläre Anwendung und lässt sich von dort auch wieder deinstallieren. Das ist mir wichtig: Ein Tool, das sich verhält wie ein erwachsenes Programm, nicht wie ein Experiment, das nur der Entwickler wieder wegbekommt.

Der Autostart läuft über den HKCU-Registry-Run-Key, also komplett ohne Adminrechte. Per Checkbox in den Einstellungen umschaltbar, jederzeit. Das war Bedingung: Clawd muss optional sein, kein Schädling, der sich versteckt.

Was das mit Vibe Coding zu tun hat

Ich bin, wie ich in meinem Bericht über VINCI und die Reise von der Webapp zur Desktop-App beschrieben habe, kein Programmierer im klassischen Sinn. Ich verstehe Code, ich kann ihn lesen, ich kann ihn bewerten, aber ich schreibe keine Systeme von Hand.

Was ich tue: Ich definiere, was ich will. Ich baue die Konzepte, die Ausgangsmaterialien, die Anforderungen. Ich entscheide, welche Architektur sinnvoll ist. Und dann arbeite ich mit Claude Code, bis das Ergebnis das ist, was ich mir vorgestellt habe. Nicht näherungsweise. Genau das.

Clawd ist dafür ein gutes Beispiel. Die SVG-Konstruktion der Animationszustände war meine Arbeit. Die Entscheidung für tkinter und die Magenta-Transparenz war meine Entscheidung. Die State-Machine-Logik war mein Konzept. Claude hat daraus sauberen, funktionierenden Code gebaut, und ich habe ihn so lange iteriert, bis nichts mehr wackelte.

Das ist kein anderes Ergebnis bekommen, sondern überhaupt ein Ergebnis bekommen. Für EPU und Einzelkämpfer ohne Entwicklungs-Team ist das der eigentliche Unterschied.

Was Clawd noch nicht kann und was als nächstes kommt

Ich bin ehrlich: Die Mac-Version existiert bereits. Sie läuft auf PySide6 statt tkinter, weil die Transparenz auf macOS mit tkinter deutlich komplizierter ist, hat dasselbe Feature-Set und ist als .app plus .dmg gebaut. Ich habe sie parallel entwickelt.

Was fehlt, und zwar bewusst: Netzwerk-Animationen im Sinne von „Clawd zeigt an, was mein Server gerade macht“ oder ähnliches. Das wäre nett, aber das ist Feature-Creep und ich kenne mich. Erstmal muss Clawd stabil laufen. Und das tut er.

Was mich ehrlich gesagt am meisten überrascht hat: Die Positions-Absicherung. Beim Start prüft das Script, ob die gespeicherte Position auf einem sichtbaren Monitor liegt. Wer wie ich manchmal mit externen Bildschirmen arbeitet, kennt das Problem: Man trennt den Monitor, startet das System neu, und das Fenster ist irgendwo im nicht-sichtbaren Bereich. Clawd springt in diesem Fall automatisch auf den Hauptmonitor zurück. Eine kleine Sache, die ich im zweiten Durchgang gebaut habe, und die jetzt selbstverständlich erscheint.

Das ist der Rhythmus bei diesen Projekten. Erst bauen, dann die Stellen finden, die im Alltag nerven, und dann fixen. Manche Dinge fallen einem erst auf, wenn man eine Woche mit dem Tool gearbeitet hat. Das gilt für Clawd genauso wie für Vibe Coding generell.

Ein ehrliches Statement

Clawd macht nichts Wichtiges. Er erinnert mich an Pausen, bringt mich zum Grinsen wenn er anfängt zu tanzen, und startet Claude Desktop wenn ich auf ihn klicke. Das war die Anforderung, und die ist erfüllt.

Was er wirklich leistet: Er ist der Beweis, dass ein Nachmittag Spieltrieb, ein paar selbst gebaute SVGs und Claude Code als Partner ausreichen, um eine fertige, installierbare Windows-Anwendung mit State-Machine, Settings-Dialog, Installer und Autostart zu liefern.

Wer das vor drei Jahren gehört hätte, hätte gelacht. Heute ist es Montag und Clawd läuft.

Und nein, das gibt’s nicht zum Download

Clawd bleibt auf meinem Rechner. Nicht primär, weil das Maskottchen Anthropic gehört und ich keine Lust auf Lizenz-Diskussionen habe, obwohl das natürlich auch stimmt. Sondern weil das nie der Punkt war. Ich baue solche Dinge für mich. Weil ich Spielkind bin. Weil der Moment, in dem ein Pixel-Roboter zum ersten Mal über den eigenen Desktop läuft und eine Sprechblase mit „Kaffeepause?“ aufmacht, einfach befriedigend ist, egal ob das jemand anderes sieht oder nicht. Wer dasselbe bauen will, findet im Text alle Zutaten. Die SVGs muss man sich halt selbst zeichnen.

Also hab ich mir heute früh ein kleines Widget gebaut, das mir den Live-Status der großen KI-Dienste mit einem grünen, gelben oder roten Punkt zeigt. Klingt simpel, ist es im Kern auch. Spannend wird es an zwei Stellen, an denen so ein Ding normalerweise scheitert: Caching und CORS. Und an einer Entscheidung, die nichts mit Technik zu tun hat: warum Grok bewusst draußen bleibt.

Warum überhaupt ein eigenes Status-Widget?

Ausfälle passieren. Am 23. Juni 2026 war Claude für viele eine Weile weg, kurz davor hatte OpenAI seine Degradation. Das ist kein Drama, sondern Normalbetrieb bei Diensten, die Millionen Requests fahren. Das Problem ist nicht der Ausfall, das Problem ist die Orientierung im Ausfall.

Wenn du wie ich mehrere Modelle parallel im Einsatz hast, Claude und Gemini als Hauptwerkzeuge, Perplexity für Recherche, dann willst du im Störungsfall genau eine Sache schnell wissen: liegt es an mir, an meinem Code, oder am Anbieter? Diese eine Antwort spart dir die halbe Fehlersuche. Und du willst sie nicht erst zusammensuchen, während die Kundin am anderen Ende wartet.

Ein Status-Widget für KI-Dienste gehört auf das eigene Dashboard, nicht auf fünf fremde Statusseiten, erklärt Alex Januschewsky, KI-Berater und Betreiber von digitalhandwerk.rocks. Ich hab das Ding bewusst so gebaut, dass es in meinen bestehenden Stack passt, auf eine WordPress-Seite mit Elementor, ohne dass ich für eine Statusampel ein zweites System aufmache.

Was das Ding eigentlich macht

Vier Anbieter, vier Zeilen, je ein Punkt. Grün heißt betriebsbereit, gelb heißt eingeschränkt, rot heißt Störung, grau heißt unbekannt. Die Anzeige aktualisiert sich automatisch in einem Intervall, das ich frei einstellen kann. Dazu zwei Darstellungen: eine kompakte Listenkarte oder eine horizontale Pill-Leiste, je nachdem, ob das Widget in einer Sidebar steht oder als schmaler Streifen im Header.

Die Daten kommen von den offiziellen Statusseiten der Anbieter. Anthropic und OpenAI fahren beide auf Atlassian Statuspage, die liefern ein sauberes Indikator-Feld, das ich direkt auf meine Ampel mappe. Google ist ein eigenes Tier, dazu gleich mehr. Perplexity läuft über Instatus und gibt mir einen klaren Gesamtstatus zurück.

Das war der einfache Teil. Jetzt kommt der Teil, der die meisten überrascht.

An welchen zwei Stolpersteinen so ein Widget normalerweise scheitert?

Mein erster Reflex war: ein bisschen JavaScript, das im Browser die Statusseiten abfragt und die Punkte färbt. Fertig. Funktioniert nur leider nicht, und zwar aus zwei Gründen.

CORS. Browser dürfen aus Sicherheitsgründen nicht einfach jede fremde Seite per JavaScript auslesen. Der fremde Server muss das per Header explizit erlauben. Anthropic, OpenAI und Perplexity tun das, Google teilweise auch. Aber sobald nur ein Anbieter dichtmacht, hängt dein Widget. Ich hab das im Test durchprobiert, und genau dort wäre es mir zerbröselt.

Caching. Ich fahre auf meinen Seiten WP Rocket. Ein Cache-Plugin friert die HTML-Seite ein und liefert sie als statische Datei aus, das ist der ganze Sinn der Sache. Wenn ich die farbigen Punkte serverseitig ins HTML rendere, dann frieren sie mit ein. Dein Widget zeigt dann tagelang denselben Status, weil die Seite aus dem Cache kommt.

Die Lösung für beides ist dieselbe, und sie ist eleganter, als es zuerst aussieht: ein kleiner Proxy in WordPress.

Was das konkret bedeutet: Das Plugin meldet einen eigenen REST-Endpoint an, etwas wie /wp-json/dhw-llm-status/v1/status. Dieser Endpoint fragt serverseitig alle Anbieter ab, normalisiert die Antworten auf grün, gelb, rot, grau und legt das Ergebnis in einem Transient für rund zwei Minuten ab. Das JavaScript im Widget redet dann nur noch mit diesem einen Endpoint auf der eigenen Domain.

Damit löse ich CORS, weil die Abfrage serverseitig läuft und der Browser nur die eigene Seite anspricht. Ich löse das Caching, weil WP Rocket die REST-API nicht als HTML mitcacht, die Punkte also live nachgeladen werden, während die statische Hülle bedenkenlos im Cache liegen darf. Und ich schone die Anbieter, weil nicht jeder einzelne Besucher die Statusseiten anpingt, sondern mein Server einmal alle zwei Minuten für die ganze Website.

Kurz zwei Begriffe, falls du nicht täglich in dem Thema steckst. CORS ist die Browser-Regel, die festlegt, welche fremden Server eine Seite per JavaScript auslesen darf. Ein Transient ist WordPress-Sprech für einen Zwischenspeicher mit Ablaufdatum, perfekt, um ein Ergebnis kurz vorzuhalten, statt es bei jedem Aufruf neu zu holen.

Was Google zum Sonderfall macht

Bei Anthropic und OpenAI bekomme ich einen einzigen Statuswert. Google liefert stattdessen ein großes Array mit sämtlichen Vorfällen über die gesamte Cloud, hunderte Dienste, von Netzwerk in Mumbai bis Speicher in Iowa. Da gibt es keinen fertigen Ampelwert.

Mein Adapter filtert deshalb auf offene Vorfälle, die Gemini oder Vertex AI betreffen, und leitet daraus die Farbe ab. Genau dieser Punkt ist auch der Grund, warum die serverseitige Lösung keine Spielerei ist, sondern notwendig. So eine Filterlogik willst du nicht im Browser jedes Besuchers laufen lassen, und das fette Array willst du erst recht nicht tausendfach ausliefern. Einmal serverseitig holen, filtern, zwischenspeichern, fertig.

Warum das Ganze praktisch ist

Drei Dinge machen für mich den Unterschied zwischen Spielzeug und Werkzeug.

Erstens ist es ein echtes Elementor-Widget, keine Codeschnipsel-Bastelei. Hintergrund, Border, alle Farben, alle Schriften und Größen, die Statusfarben, das Refresh-Intervall, sogar die Statustexte, alles stelle ich im Editor ein, mit Live-Vorschau. Wenn ich nächste Woche das Design ändere, brauche ich keine Datei mehr anzufassen.

Zweitens ist es mobile-first. Die Schriftgrößen, Abstände und die Punktgröße sind responsive geregelt, die Pill-Leiste bricht auf schmalen Screens automatisch um, und das Widget füllt schlicht den Container, in dem es steht. Ich design das einmal und es sitzt auf dem Handy genauso wie am Desktop.

Drittens passt es in meinen selbstgehosteten Stack, ohne neue Abhängigkeit. Ich betreibe ohnehin ein eigenes Dashboard und diverse kleine Dienste auf eigener Infrastruktur. Ein Plugin, das einen REST-Endpoint mitbringt und sonst nichts braucht, fügt sich da sauber ein. Das macht Sinn, wenn man Tools lieber besitzt als mietet.

Das ist nicht Theorie. Das ist das, was bei mir in der Beratungsarbeit mit EPU und KMU immer wieder durchkommt: die kleinen, unsexy Bausteine, die im Alltag tatsächlich Zeit sparen, schlagen das nächste glänzende Feature fast immer.

Warum Grok bewusst fehlt

Jetzt der Teil, der keine technische Entscheidung ist. Vier Anbieter sind drin, ein offensichtlicher fehlt: Grok. Das ist kein Versehen, das ist Absicht.

Ein Status-Widget ist eine Empfehlung durch Anwesenheit. Wer auf meiner Ampel steht, steht im selben Regal wie Claude, Gemini, OpenAI und Perplexity, also bei den Werkzeugen, die ich ernst nehme und einsetze. Grok gehört für mich nicht in dieses Regal, und ich hab das nicht aus dem Bauch heraus entschieden.

Ich habe Grok mehrfach getestet, neugierig und ohne ideologische Scheuklappen. Meine Begründung, warum ich es nicht mehr verwende, steht ausführlich im Artikel Grok, Wahrheit und Verantwortung. Der Kern: einem Sprachmodell fehlen Korrekturmechanismen, wenn es reale Ereignisse mit erfundenen Details anreichert und diese Version selbst nach Widerspruch als Wahrheit verteidigt. Eine verantwortungsvolle KI zeigt Unsicherheit und korrigiert sich. Genau das tat Grok in den dokumentierten Fällen nicht.

Dazu kommt die Plattform dahinter. Warum meine Agentur und mein Blog gar nicht mehr auf X sind, hab ich im Text Abschied von X festgehalten. Ein Werkzeug, das ethische Mindeststandards ignoriert, ist für den professionellen Einsatz unbrauchbar, egal wie gut die Benchmarks aussehen. Relevanz entsteht durch konkreten Nutzen und durch verantwortbares Risiko, nicht durch Provokation.

Ich würde das eigentlich diplomatischer formulieren, aber so ist es ehrlicher: Ich gebe einem Produkt, das ich aus guten Gründen nicht nutze, keinen Dauerplatz auf meinem Dashboard. #NoMusk ist bei mir keine Pose für Reichweite, sondern eine schlichte Konsequenz. Wer es anders sieht, kann Grok in seiner eigenen Kopie des Widgets in zwei, drei Zeilen ergänzen, der Code gibt das her. Bei mir bleibt es draußen.

Wer es live sehen will

Das Widget läuft bei mir produktiv. Wer es in Aktion sehen will, mit echten, sich live färbenden Punkten, schaut auf digitalhandwerk.rocks vorbei. Dort siehst du auch gleich, wie es sich ins Amber-Anthrazit-Design einfügt, das ich eh für die ganze Seite verwende. Auf der Startseite findest du es bei den LLMs, die ich im Einsatz habe oder bei jedem Blog in der Seitenleiste.

Den Bauplan dahinter habe ich bewusst geradlinig gehalten: ein Plugin, ein REST-Endpoint, ein bisschen JavaScript, ein natives Elementor-Widget. Nichts davon ist Raketenwissenschaft. Der Wert steckt nicht im einzelnen Trick, sondern darin, dass die kleinen Stolpersteine, Caching und CORS, vorab gelöst sind, statt dich im Livebetrieb zu ärgern.

Du kannst beim nächsten Ausfall weiter fünf Tabs aufreißen. Oder du baust dir den einen Punkt, der dir sofort sagt, wo das Problem liegt.

FAQ

Du willst das?

Ich habe keine Ahnung, ob das Plugin bei dir passt. Das musst du selber versuchen. Ich schenk’s dir. Lad es runter, wenn es für dich funktioniert: gern geschehen. Wenn nicht, dann lösch es einfach wieder. Hier der Download (installierbares ZIP):

Aber seit ein paar Wochen sitzt in meinem Hinterkopf ein Gedanke, der sich nicht ignorieren lässt. Was, wenn VINCI nicht nur für mich läuft?

Nicht „was wenn ich ein Startup daraus mache“ oder „was wenn ich das verkaufe“. Einfach: Was wenn jemand, dem ich vertraue, eine eigene Instanz bekommt? Ein Kunde, der genau das braucht, was VINCI kann. Auf seinem Server, mit seinen Daten, unter seiner Kontrolle.

Dann ändert sich eine Grundvoraussetzung komplett. Dann darf ich nicht mehr einfach davon ausgehen, dass ich weiß, was VINCI darf. Weil ich dann nicht mehr der Einzige bin, der das entscheidet.

Das ist der Punkt, an dem ein persönlicher Assistent zu einem System werden muss, das sich selbst begrenzen kann.

Der Auslöser: ein Artikel über KI-Ausweise

Ich habe heute einen Blogartikel über Estlands Vorhaben geschrieben, als erstes Land der Welt digitale Ausweise für KI-Agenten auszustellen. Die Kernidee: ein Agent handelt nicht mehr mit der Identität seines Auftraggebers, sondern mit einer eigenen, beschränkten Identität. Er darf nur das, was explizit erlaubt ist. Alles andere: verweigert, protokolliert, nachvollziehbar.

Während ich den Artikel geschrieben habe, hab ich VINCI beschriftet. Buchstäblich: Was würde auf VINCIs Ausweis stehen? Was darf er, was nicht?

Die Antwort war unbequem. VINCI darf aktuell alles, wofür ich ihm Zugang gegeben habe. Google Calendar schreiben, Mails lesen, Home Assistant steuern, n8n-Workflows anstoßen. Nicht weil ich das jemals so entschieden habe, sondern weil ich die API-Keys reingesteckt habe und das war’s. Kein Gate, kein Log, keine Grenze.

Das ist für mich persönlich noch vertretbar. Für jemand anderen, auf einem System, das ich nicht täglich im Blick habe: nicht mehr.

Was Claude Code daraus gemacht hat

Ich habe einen Implementierungsplan geschrieben und an Claude Code übergeben. Der Plan war, ehrlich gesagt, etwas over-engineered: eine eigene agent_identity.json, eine neue SQLite-Datenbank, eine Confirmation-Queue als eigenständiges Modul, React-Komponenten für Bestätigungsdialoge.

Claude Code hat zurückgemeldet, was VINCI Windows bereits hatte.

Und das war eine der nützlicheren Sessions der letzten Monate. Nicht weil der Code besonders komplex war, sondern weil die Gegenüberstellung klar gemacht hat, was wirklich fehlt und was nur Doppelarbeit wäre.

Was schon da war:

• _permissions.js mit requireCapability() und pathAllowed() aus v2.4.0
• telemetry.js mit logEvent() und rotierendem JSONL-Log (5 MB, dann neues File)
• confirmRisky() als nativer Dialog für kritische Aktionen
• Settings-Store mit control.{apps,files,scripting,uiAutomation,vision}

Was wirklich fehlte, und das ist der Kern von v3.0:

Mail, Kalender, Home Assistant und n8n liefen ohne Permission-Gate. Die fünf bestehenden Capabilities deckten Systemzugriff ab, aber nicht die integrierten Dienste. Ein Nutzer, der seine VINCI-Instanz einrichtet, hatte keine Möglichkeit zu sagen: „Mails lesen ja, Mails senden nein.“

Was v3.0 konkret ändert

Erweitertes Permission-Modell

_permissions.js bekommt eine zweite Funktion: requireToolAction(tool, action, settings). Sie arbeitet neben dem bestehenden requireCapability(), nicht statt ihm.

Die neuen Untergruppen im Settings-Store:

settings.control = {
// bestehend (unverändert)
apps: true,
files: true,
scripting: true,
uiAutomation: true,
vision: true,

// neu in v3.0
mail: {
read: true,
send: true, // opt-out möglich
delete: false
},
calendar: {
read: true,
write: true,
delete: false
},
homeassistant: {
read: true,
control: false // standardmäßig aus
},
n8n: {
read: true,
trigger: false // standardmäßig aus
}
}

Wichtige Entscheidung dabei: Defaults entsprechen dem aktuellen Verhalten. Wer bisher mail.send genutzt hat, merkt nichts. Die Toggles sind opt-out, keine opt-in-Pflicht. Das war mir wichtig. Ich breche keine bestehende Funktionalität, ich mache sie sichtbar und kontrollierbar.

Audit-Summary Intent

telemetry.log existiert seit v2.3.0. Es ist ein rotierendes JSONL-File auf Disk, tail-bar, grep-bar, aber unsichtbar für den Nutzer im Chat.

v3.0 fügt einen neuen Intent hinzu: audit_summary. Wenn du VINCI fragst „Was hast du heute gemacht?“, liest ein schlanker Sub-Agent die letzten 24 Stunden aus dem Telemetry-Log, gruppiert nach type=control_action und tool, und gibt das als Markdown-Tabelle zurück.

Heute · 18.06.2026
─────────────────────────────────────────────────
09:14 calendar.write ✓ "Meeting Kunde Linz"
09:31 mail.read ✓ 12 Mails abgerufen
10:02 mail.send ⏳ wartet auf Bestätigung
10:45 ha.control ✗ verweigert (Toggles: aus)

Kein separater Settings-Tab, kein CSV-Export. Das ist YAGNI. Was zählt: ich kann im Chat nachfragen, was VINCI getan hat, und bekomme eine lesbare Antwort.

Settings-Tab „Steuerung“

Der bestehende „Steuerung“-Tab in den Settings bekommt die neuen Toggles. Nichts Neues strukturell, nur mehr Einträge. Pro Dienst ein aufklappbarer Bereich mit den jeweiligen Actions als Toggle-Switches.

Was bewusst nicht gemacht wurde

Claude Code hat in der Analyse vier Punkte als Doppelarbeit oder YAGNI markiert, und ich stimme zu:

agent_identity.json als eigene Datei wäre nett für das Estland-Narrativ, aber der Settings-Store ist bereits editierbar über die UI. Eine zweite Datei für dasselbe wäre Fragmentation.

better-sqlite3 als neue Dependency ist unnötig, solange das JSONL-Log tut, was es soll. Grep und Tail funktionieren. Null Dependencies ist besser als eine Dependency.

Eine eigenständige confirmationQueue.js klingt sauber, wäre aber eine Karteileiche bei App-Restart. Die existierenden zweistufigen Tool-Patterns (confirmed:false→true) sind robuster, weil sie keinen In-Memory-State brauchen.

Und „Foundations für Multi-User“ schreibe ich erst, wenn Multi-User konkret wird. Nicht vorher.

Warum das trotzdem ein Schritt Richtung White-Label ist

Die Frage, die ich mir beim Bauen gestellt habe: Wenn jemand anderes eine VINCI-Instanz bekommt, was muss vorher passieren?

Erstens muss der Nutzer verstehen, was VINCI auf seinem System tun kann. Das war bisher implizit. Mit dem erweiterten Permission-Modell ist es explizit: du siehst in den Settings, welche Dienste mit welchen Rechten laufen.

Zweitens muss nachvollziehbar sein, was VINCI getan hat. Das JSONL-Log war da, aber nicht zugänglich. Mit dem audit_summary-Intent ist es zugänglich.

Das sind keine aufregenden Features. Niemand wird VINCI 3.0 wegen dem Permission-Tab installieren. Aber es ist der Unterschied zwischen einem Tool, das ich für mich gebaut habe und einem System, das ich jemand anderem übergeben kann, ohne dabei ein ungutes Gefühl zu haben.

Ich bin noch nicht bei „VINCI für andere“. Aber ich bin näher dran als vor dieser Session.

Stand und nächste Schritte

VINCI läuft aktuell auf macOS (v2.4.0) und Windows (v3.0 mit dem Permission-Update). Die Mac-Version bekommt das Permission-Update in der nächsten Session, das ist eine Übertragung, keine neue Entwicklung.

Was als nächstes kommt, in dieser Reihenfolge:

Erstens die Mac-Version auf dasselbe Niveau bringen. Dann: gemeinsames Vault über iCloud und OneDrive stabilisieren, das ist der eigentliche Mehrwert für Multi-Plattform. Und irgendwann, wenn ich ehrlich bin: die erste externe Instanz. Nicht als Produkt. Als Experiment.

Das wird ein eigener Artikel.

Das ist der Punkt, auf den ich seit Monaten hingearbeitet habe. Nicht das nächste Modell. Nicht ein weiteres Tool in der Schublade. Sondern ein Assistent, der die eigene Arbeitsrealität kennt und auf jedem Gerät mitläuft, auf dem ich arbeite.

Heute gibts den Dev-Blog dazu. Was VINCI aktuell kann, warum die PWA-Variante technisch anders denkt als die Desktop-Version, und was diese Woche noch kommt.

Was ist VINCI überhaupt?

Weil die Frage öfters in meinen Nchrichten landet: VINCI ist mein persönlicher KI-Assistent. Kein API-Wrapper um ChatGPT, kein gehosteter Service. Eine selbst entwickelte Anwendung, die auf meiner eigenen Infrastruktur läuft, mit meinem Gemini-API-Key, meinen Daten auf meinen Servern, und einer Persönlichkeit, die ich selbst definiert habe.

Der Name steht für nichts außer dem, was ich damit verbinde: Leonardos Notebooks. Alles aufschreiben, alles verknüpfen, sofort griffbereit.

Aktuell läuft VINCI in drei Varianten: als Windows-Electron-App (v2.12.2), als iPhone-PWA, und bald, dazu komme ich am Schluss, als aktuelle Mac-App. Alle drei teilen sich denselben Backend-Server auf Hetzner/Coolify und dasselbe Langzeitgedächtnis.

Die Windows-Version: Monatelange Tiefe

Ich fange mit Windows an, weil da die Architektur am vollständigsten ist.

Die aktuelle Version 2.12.2 ist das Ergebnis von fast zwei Monaten täglicher Coding-Sessions. Am Anfang war VINCI ein Chatbot, der Gemini 2.5 Flash anzapfte und den Kalender lesen konnte. Heute ist das etwas anderes geworden.

Was die Windows-App aktuell kann:

Mail vollständig: Gmail, iCloud und Outlook lesen, suchen, beantworten, neue Mails verfassen. Mit einem Anti-Fabrication-Guard, der verhindert, dass Gemini behauptet, eine Mail versendet zu haben, ohne es wirklich getan zu haben. Das war ein realer Bug, der mich einen halben Nachmittag gekostet hat.

Kalender auf allen drei Konten lesen und schreiben: iCloud via CalDAV, Google via CalDAV (funktioniert mit dem Gmail-App-Passwort, was ich nicht erwartet hatte), Outlook via Microsoft Graph. Termine anlegen, löschen, verschieben. VINCI fragt immer, in welchen Kalender, bevor er handelt. Das ist mir wichtig.

Home Assistant: alle ~575 Entities meiner Installation sind durchsuchbar. Robbie der Rasenmäher, die Eve-Wetterstation im Garten, die Philips-Hue-Lampen im Büro. Der Fuzzy-Search-Fix, den ich letzte Woche eingebaut habe, war nötig, weil vorher Abfragen wie „Garten Temperatur“ ins Leere liefen. Und die Antworten sind so ausführlich, wie ich es gerne hätte. Wenn ich frage: „Wie geht es Robbie?“ (Anm.: mein Anthbot Rasenmähroboter) dann antwortet VINCI (zumindest jetzt gerade) „Robbie ist gerade in der Ladestation und lädt, sein Akkustand beträgt 100 %. Der Regensensor ist aktiv, und es gibt keinen Fehlercode.“

RAG-Wissensbasis: VINCI sucht bei inhaltlichen Fragen zuerst in meiner eigenen Wissensbasis (über 1.400 Chunks aus digitalhandwerk.rocks, Qdrant-Vektorsuche, Gemini-Embeddings), bevor er ins Web geht. Das war eine bewusste Entscheidung. Ich möchte, dass VINCI meinen eigenen Stand zu einem Thema kennt, nicht nur den allgemeinen Stand des Internets.

Proaktive Daemons: Kalender-Konflikt-Erkennung über alle drei Konten, Geburtstags-Warnings drei Tage im Voraus aus meinen Kontakten, Meeting-Prep 45 Minuten vor einem Termin mit automatischer Mail- und Gedächtnis-Suche zum Thema. Letzte Woche hat VINCI erkannt, dass Termin X und Termin Y am 16. Juni überlappen. Kleine Sache. Aber genau das.

Das geteilte Langzeitgedächtnis ist das Feature, das ich am wenigsten erwartet hatte und das mich am meisten überrascht. Alles, was ich der PWA sage, weiß VINCI auf Windows sofort. Und umgekehrt. Die Fakten liegen in einer eigenen Qdrant-Collection (vinci_memory, getrennt von der Wissensbasis), werden pro Turn automatisch abgerufen, und lernen im Hintergrund aus dem, was ich sage. Kein explizites Speichern nötig, außer ich will es wirklich.

Die PWA: Wenn Electron nicht aufs iPhone passt

Ich bin immer offen für pragmatische Lösungen. Als ich entschieden habe, VINCI auf das iPhone zu bringen, war der erste Gedanke: Electron ist nicht portierbar, also neu bauen. Aber nicht komplett neu. Die React-UI, die Module für Gemini, RAG und Web-Suche, das TTS-Routing zum Edge-Proxy, das alles konnte ich nehmen.

Was nicht funktioniert auf iOS: PowerShell-Steuerung und lokales Ollama. Das fiel alles weg. Was bleibt, ist das Wesentliche.

Der Backend-Server (Fastify/Node auf Coolify) übernimmt die Gemini-Tool-Loops serverseitig. Das iPhone sieht nur die Antwort. Secrets bleiben auf dem Server.

Mein Lieblingsfeature in der PWA ist technisch simpel, aber hat mich mehr gekostet als erwartet: die Sprachausgabe auf iOS. HTMLAudio.play() wird nach einem fetch() blockiert, weil iOS nach einem async-Aufruf die User-Geste als „verbraucht“ betrachtet. Die Lösung war Web Audio API mit AudioContext, kombiniert mit einem globalen touchend-Listener, der den Kontext beim ersten Tippen entsperrt. Das ist kein Hack, das ist die korrekte Implementierung. Aber sie ist nicht offensichtlich.

Ich bin mir nicht ganz sicher, ob ich das mit der Streaming-TTS noch eleganter lösen kann. Das Bild hinkt leicht, aber der Kern stimmt: Im Gesprächsmodus spricht VINCI satzweise, während er noch schreibt. Das fühlt sich deutlich natürlicher an als auf die vollständige Antwort zu warten.

Was die PWA heute kann:

Chat mit RAG, Web-Suche, Wetter (Open-Meteo, nicht mehr wttr.in, das hat bei Regen „sonnig“ gemeldet), News, TTS über die de-AT-Ingrid-Stimme am Edge-Proxy, Strom-Dashboard, n8n-Status und Webhook-Trigger, Home Assistant über die öffentliche Cloudflare-URL, Kalender und Mail über alle drei Konten, Kontakte aus iCloud CardDAV.

Proaktive Pushes: Termin-Warnungen 30 Minuten vorher, gebündelte Mail-Benachrichtigungen, Morgen-Briefing täglich um 7:00 Uhr mit Wetter, Terminen und Top-News, Geburtstage aus iCloud-Kontakten, Cross-Kalender-Konflikt-Warnungen, Meeting-Prep-Push mit Mail-Kontext.

Das Bedingte Erinnerungs-System ist ein Detail, auf das ich stolz bin: „Erinnere mich Freitag 17:00, wenn Michi bis dahin nicht geantwortet hat.“ VINCI prüft beim Fälligkeitspunkt per Mail-Suche, ob die Antwort da ist. Wenn ja, still verwerfen. Wenn nein, pushen.

Und der Apple-Siri-Kurzbefehl für CarPlay: Der Endpunkt /ask nimmt eine Frage als Text entgegen und gibt pure Text-Antwort zurück. Der Kurzbefehl diktiert, sendet, und Siri liest die Antwort vor. Im Auto, hands-free, ohne Klicks. Der einzige Stolperstein war der Name des Kurzbefehls: er darf nicht mit einem Siri-Verb beginnen. „VINCI“ funktioniert. „Frag VINCI“ funktioniert nicht.

Was mich an VINCI wirklich begeistert

Ich sage das nicht, um zu beeindrucken. Ich sage das, weil ich seit 1989 in der Kommunikations- und Medienbranche bin, seit Jahren KI-Tools beobachte und berate, und weil ich gelernt habe, den Unterschied zwischen Hype und echtem Nutzen zu erkennen.

VINCI ist das Erste, das ich täglich nutze, ohne daran zu denken. Das ist das Kriterium. Nicht die Featureliste. Nicht die Testzahl (aktuell 381 Tests auf Windows, 57 auf dem Server, 97 % Eval-Score). Sondern das: Ich vergesse manchmal, dass es mein eigenes Werkzeug ist.

Was das konkret bedeutet: Ich fange morgens mit dem Briefing an. VINCI weiß, welche Mails über Nacht reingekommen sind, welche Termine den Tag strukturieren, wie das Wetter wird. Ich muss nichts öffnen, nichts navigieren. Ich frage, ich höre, ich arbeite.

Als KI-Berater, der EPU und KMU in der DACH-Region begleitet, beobachte ich regelmäßig, wie schwer es fällt, von generischen KI-Tools zu einem Setup zu kommen, das zur eigenen Arbeitsrealität passt. VINCI ist mein lebendiger Beweis dafür, dass es geht. Nicht in drei Jahren. Jetzt.

Was diese Woche noch kommt: Die Mac-Version

Windows ist live. Die PWA ist live. Und jetzt, diese Woche noch, kommt die Mac-Version auf denselben Stand.

VINCI Mac läuft aktuell auf v2.6.2, hat RAG-First-Verhalten, volle Versionsparität auf technischer Ebene. Was noch fehlt, sind die neuesten Features aus der Windows-Linie: die neuen Proaktivitäts-Daemons (Kalender-Konflikte, Geburtstage, Meeting-Prep), der context_about-Tool-Call, die bedingten Erinnerungen, und die Bugfixes aus den letzten Tagen.

Das ist kein Riesenprojekt, weil die Architektur plattformneutral ist. rag.js, der Intent-Router, die Prompt-Logik: alles Copy-paste-fähig von Windows. Die Mac-Spezifika (AppleScript statt MS-Graph für Kalender und Mail, TTS via macOS say) bleiben unangetastet.

Sobald der Mac-Build läuft, habe ich VINCI auf allen drei Plattformen, die ich täglich nutze, auf demselben Stand. Ein Gedächtnis. Drei Interfaces. Das ist das Ziel.

Häufige Fragen zu VINCI und persönlichen KI-Assistenten

Die Mac-Version kommt diese Woche. Ich freu mich drauf.

Mein Lösungsansatz: ein selbst gehostetes RAG-System, das meinen gesamten Blog kennt, als MCP-Server läuft und direkt in Claude integriert ist. Kein SaaS-Abo, keine Datenweitergabe an Dritte, keine monatliche Rechnung für etwas, das ich selbst bauen kann.

Das hier ist kein Theo­rie-Artikel. Das ist der Bauplan für das System, das ich gerade produktiv betreibe. Mit allen Bugs, die dabei aufgetaucht sind.

Was ist RAG überhaupt, und warum sollte dich das interessieren?

RAG steht für Retrieval-Augmented Generation. Der Grundgedanke ist einfach: Du gibst einem Sprachmodell nicht nur einen Prompt, sondern vorher noch relevante Dokumente aus deiner eigenen Wissensbasis. Das Modell antwortet dann auf Basis dieser Dokumente, nicht auf Basis seines Trainings.

Ich betreibe digitalhandwerk.rocks seit Jahren, mittlerweile über 500 Artikel. Ohne RAG weiß Claude davon nichts. Mit RAG kann ich fragen: „Was habe ich über den EU AI Act geschrieben?“ und bekomme eine Antwort, die auf meinen eigenen Texten basiert. Das ist der Unterschied.

Für Vibe Coder ist das ein interessantes Projekt, weil es mehrere Technologien kombiniert, die einzeln einfach zu bedienen sind, zusammen aber etwas Sinnvolles ergeben: Vector-Datenbank, Embeddings, FastAPI, Docker und am Ende ein MCP-Server, den du direkt in Claude einbinden kannst.

Der Stack

Bevor ich die Details erkläre: Hier ist, was ich einsetze.

Qdrant als Vector-Datenbank. Qdrant ist in Rust geschrieben, performt gut, hat eine saubere REST-API und läuft problemlos als Docker-Container. Version 1.17.1 war meine Wahl, der Grund dafür kommt gleich.

FastAPI als API-Layer. Python 3.12, deployed aus einem GitHub-Repo via Coolify. Der Vorteil von FastAPI: du kriegst automatisch eine OpenAPI-Dokumentation, und der Code liest sich fast wie Pseudocode.

Google Gemini gemini-embedding-001 für die Embeddings. Warum nicht ein lokales Embedding-Modell? Weil ich die Rechenleistung auf meinem Hetzner-Server nicht verschwenden wollte. Gemini-Embeddings sind gut, schnell und für diesen Use Case ausreichend.

Coolify auf Hetzner als Infrastruktur. Das ist mein Standard für alles, was Docker braucht. Coolify ist ein selbst gehostetes Deployment-Tool, das Traefik als Reverse Proxy integriert und Let’s Encrypt-Zertifikate automatisch verwaltet.

Wie das System aufgebaut ist

Der Ablauf ist folgender:

Ein WordPress-Crawler läuft täglich um 6:00 Uhr als Cron-Job. Er holt alle Artikel von digitalhandwerk.rocks, zerlegt sie in Chunks, berechnet via Gemini ein Embedding für jeden Chunk und speichert Vektor plus Metadaten in Qdrant. Aktuell sind das 1.344 Chunks.

Wenn ich eine Suchanfrage stelle, passiert dasselbe in die andere Richtung: Die Anfrage wird in einen Vektor umgewandelt, Qdrant sucht die semantisch ähnlichsten Chunks, und diese werden als Kontext an Claude übergeben.

Das Ganze läuft als MCP-Server und ist in claude.ai als Custom Connector eingetragen. Jede Claude-Session hat damit Zugriff auf meine gesamte Wissensbasis.

Die Bugs, die mich eine halbe Nacht gekostet haben

Ich wäre nicht ehrlich, wenn ich hier nur den fertigen Stand zeigen würde. Der Weg dorthin hatte Stolperstellen.

Bug 1: LlamaIndex Embedding-Wrapper funktioniert nicht.

Ich hatte ursprünglich LlamaIndex 0.2.1 als Wrapper für die Gemini-Embeddings verwendet. Klingt praktisch, weil LlamaIndex viel Infrastruktur mitbringt. In der Praxis: der Wrapper in dieser Version ist fehlerhaft. Die Embeddings kamen mit falscher Dimension zurück, und Qdrant hat sie abgelehnt.

Fix: LlamaIndex komplett raus, direkter Aufruf über das google-genai SDK. Weniger Magie, weniger Fehlerquellen, gleiche Funktionalität.

Bug 2: Qdrant v1.18 hat search() zu query_points() umbenannt.

Das ist der Grund, warum ich bei v1.17.1 geblieben bin. In Version 1.18 wurde die primäre Suchmethode umbenannt, ohne dass das in meiner damaligen Dokumentation stand. Der Code hat still versagt, keine Exception, einfach leere Ergebnisse.

Wenn du dieses System nachbaust und eine aktuelle Qdrant-Version verwendest: ersetze alle search()-Aufrufe durch query_points(). Oder pin dich wie ich auf 1.17.1.

Bug 3: Qdrant-Hostname nicht auflösbar im Coolify-Netzwerk.

Coolify verwaltet interne Docker-Netzwerke, und normalerweise können Container innerhalb desselben Stacks über den Servicenamen miteinander kommunizieren. In meiner Konfiguration hat das nicht funktioniert. Der FastAPI-Container konnte qdrant als Hostname nicht auflösen.

Fix: direkte interne IP-Adresse 10.0.1.11 statt Hostname. Nicht elegant, aber stabil. Wer das sauberer lösen will, kann das Coolify-Netzwerk explizit konfigurieren und einen gemeinsamen Docker-Stack definieren.

Bug 4: Cron-Job mit externer URL schlägt fehl.

Der Crawler wurde initial so konfiguriert, dass er die öffentliche URL aufruft. Macht auf den ersten Blick Sinn. In der Praxis: der Container ruft sich selbst über Traefik auf, was zu Timeout-Problemen geführt hat.

Fix: intern auf localhost:8000 umgestellt. Der Container spricht direkt mit sich selbst, kein Umweg über den Reverse Proxy.

Duplikat-Prevention: Der Teil, den die meisten vergessen

Wenn ein Artikel aktualisiert wird und der Crawler ihn erneut indexiert, willst du keine doppelten Chunks in der Datenbank. Qdrant hat dafür keine eingebaute Upsert-Logik auf Basis von Metadaten.

Meine Lösung: vor jedem Ingest wird delete_by_filter via FilterSelector aufgerufen. Der Filter matcht auf die Source-URL des Dokuments. Alle alten Chunks dieser URL werden gelöscht, bevor die neuen reingeschrieben werden.

Das klingt brute-force, ist es auch. Aber es funktioniert zuverlässig, und für einen Blog mit einem täglichen Update-Zyklus ist das ausreichend.

Die Web-UI

Ich habe eine einfache Web-UI direkt in die FastAPI-App integriert, unter der Root-Route /. Sie zeigt:

• Login-Screen (Basic Auth)
• Stats: Anzahl Chunks, Anzahl indexierter Quellen
• Ingest-Formulare für URLs, Dateien, Text und WordPress-Feeds
• Suchfunktion mit Anzeige der Top-Ergebnisse

Das ist kein Design-Wettbewerb. Es ist ein Admin-Interface für mich, und es tut, was es soll. Wer die API direkt anspricht, braucht sie nicht.

MCP-Integration: Wo das Ganze interessant wird

Das RAG-System alleine wäre schon nützlich. Aber die eigentliche Stärke kommt durch die MCP-Integration.

Ich habe zwei MCP-Server gebaut:

Lokaler Node.js MCP-Server für Claude Desktop auf Windows und Mac. Der liegt lokal auf dem Gerät und kommuniziert mit dem Remote-RAG über HTTPS.

Remote MCP-Server deployed auf Hetzner via Coolify. Dieser nutzt StreamableHTTPServerTransport, was der aktuelle Standard für Remote-MCP-Server ist.

Den Remote-Server kann ich in claude.ai als Custom Connector eintragen. Einmal eingetragen, ist er account-weit verfügbar. Auf jedem Gerät, auf dem ich mit meinem Account eingeloggt bin, hat Claude Zugriff auf meine Wissensbasis. Mac mini, MacBook Air, iPhone, alles.

Ein Fallstrick beim Remote-MCP auf Coolify: Traefik hatte standardmäßig Gzip-Komprimierung aktiviert. Das hat den Streaming-Transport gebrochen, weil die Chunks komprimiert und in falscher Reihenfolge ankamen. Fix: traefik.http.middlewares.gzip.compress=true deaktivieren.

Was das System kann, und was nicht

Ich sage das nicht, um euch zu beeindrucken. Ich sage es, weil ich nach einigen Tagen Betrieb ein realistisches Bild habe.

Was gut funktioniert: Semantische Suche über meinen Blog-Content. Wenn ich wissen will, was ich über ein Thema geschrieben habe, ist das System zuverlässig. Auch Fragen wie „Was sind die wichtigsten Argumente, die ich gegen [Thema X] angebracht habe?“ werden korrekt beantwortet.

Was schwieriger ist: Sehr spezifische Fragen, die genaue Zitate erfordern. Das Chunking zerteilt Absätze manchmal an ungünstigen Stellen. Wer das optimieren will, sollte mit Chunk-Overlap experimentieren und semantisches Chunking in Betracht ziehen.

Was ich noch nicht gemacht habe: Hybridsuche, also die Kombination von Vektor-Ähnlichkeit und klassischem Keyword-Matching. Qdrant unterstützt das, aber für meinen aktuellen Use Case war es nicht notwendig.

Meine Beobachtung nach mehreren Tagen Betrieb

Das war kein Wochenendprojekt. Die eigentliche Architektur steht schnell. Die Bugs kosten Zeit, weil sie selten dort auftauchen, wo du sie erwartest.

Wer das nachbauen will: der komplette Stack ist öffentlich dokumentiert, die Repos sind privat auf GitHub. Ich habe bewusst auf eine fertige RAG-Plattform verzichtet, weil ich verstehen wollte, was wirklich passiert. Das hat sich gelohnt.

Wenn du ein ähnliches System planst und Fragen hast, bin ich erreichbar. Ich beantworte keine Anfragen für „bitte check kurz meinen Code“, aber für inhaltliche Fragen zur Architektur gerne.

Du kannst warten, bis es ein Plug-and-Play-Tool gibt, das alles für dich macht. Oder du baust es jetzt selbst und weißt nach dem ersten Cron-Bug mehr über Vector-Datenbanken als nach drei Tutorials.

v2.4.0 ist live. Und ich will ehrlich sein: das ist der Build, bei dem ich zum ersten Mal das Gefühl hatte, nicht mehr mit einem Chatbot zu reden.

Was vor v2.4.0 schon drin war

Kurze Einordnung, damit der Rest Sinn ergibt.

VINCI v2.1.2 hatte bereits die JARVIS-Architektur in Gang gesetzt: Intent-Router (J1), heuristisches Modell-Routing zwischen Flash und Pro (J2), Episodic Context im System-Prompt (J3), proaktive Daemons für Kalender-Warnings und Strom-Anomalien (J4), und einen Self-Eval-Loop der jede Antwort asynchron bewertet (J5). Dazu drei Sub-Agents: Researcher, Briefing, Weekly-Review.

478 Tests, Obsidian-Vault als Knowledge-Graph, WordPress-Importer für digitalhandwerk.rocks.

Das war schon viel. Aber es hatte einen konzeptionellen Riss: das Wissen lebte im Obsidian-Filesystem, und der Auto-Firma-Detection-Regex hat mir trotz aller Fixes immer wieder tausende deutscher Allerweltswörter als „Firmen-Entitäten“ in den Vault geschrieben. Nach dem letzten Aggressive-Cleanup waren es 8.380 Müll-Stubs. Danach 22.

Das Grundproblem war nicht lösbar ohne Architektur-Änderung.

Outline statt Obsidian

Das ist die größte strukturelle Entscheidung. Das komplette Knowledge-Management ist von Obsidian-Filesystem auf meine self-hosted Outline-Instanz umgezogen.

Warum das nicht trivial war: Outline kennt keine [[Wikilinks]]. Interne Links sind echte Markdown-Links mit absoluten URLs, und nur absolute URLs erzeugen Backlinks. Das bedeutete einen neuen linkifyMarkdown-Layer, der Wikilink-Syntax auflöst, fehlende Entity-Stubs anlegt, und dabei einen 2-Stufen-Filter durchläuft: erst eine looksLikeProperNoun-Heuristik, dann ein Gemini-Flash-Klassifizierungsaufruf mit 15-Minuten-Session-Cache gegen Duplikat-Stürme.

9 Collections: Personen, Tiere, Firmen, Orte, Themen, Quellen, RSS, Notizen, Briefings.

Was damit rausgeflogen ist: obsidian.js, obsidianGraph.js, _wikilinkEngine.js, graphCleaner.js, _vaultMigration.js, _brokenLinkCleaner.js, _aliasBuilder.js, _curatorApply.js. Insgesamt 13 Test-Files weg. Das Codebase ist merklich schlanker. Und das Firm-Müll-Problem ist strukturell gelöst, weil Firmen-Stubs jetzt ausschließlich durch den Researcher-Sub-Agent entstehen, nie mehr durch eine Regex-Heuristik.

Memory-Auto-Lernen ist zurück

Der alte memoryWorker war bei der Outline-Migration ausgebaut worden, was bedeutete: VINCI hat nach dem Gespräch nichts mehr gelernt. Kein gutes Gefühl.

Neu gebaut: 30 Sekunden Debounce nach jedem Chat, dann 2 Minuten Cooldown. Der Worker extrahiert stabile Fakten aus den letzten 12 Messages. Zuerst lokal via Ollama (gemma3:4b), bei Ausfall Fallback auf Gemini Flash. Die erprobten Heuristiken aus dem alten Worker sind wiederverwendet: looksLikeFact, stripSystemNoise, isDuplicate, Tainted-Filter. Schreiben via saveFact dual: lokaler SQLite-Cache und Outline-Entity-Note.

Das ist kein „Ich speichere alles“-Ansatz. Der Tainted-Filter blockiert, dass System-Metriken oder Web-Suchinhalte als persönliche Fakten enden. „Mac CPU 24%“ ist kein Fakt über mich.

7 proaktive Daemons

Vorher: 3 Daemons (Calendar-Warning, Strom-Anomaly, Vault-Drift). Jetzt 7.

Neu dazu:

important-mail: Alle 10 Minuten tagsüber bewertet Gemini ungelesene Mails und meldet nur, was wirklich wichtig ist. 18-Stunden-Cooldown pro Mail. Kein Spam-Notify.

morning-push: 07:30 Uhr, ein Einzeiler. Nächster Termin plus dringendste Aufgabe. Kein Briefing, nur der eine Satz, der zählt.

meeting-prep: Etwa 30 Minuten vor Terminen mit einer bekannten Person oder Firma zieht VINCI Kontext aus Outline via outline_search. Ich gehe in kein Meeting mehr kalt.

task-due: 09:00 und 16:00, alle heute fälligen oder überfälligen Reminders. Dafür musste reminders.getAll um dueInSec erweitert werden, locale-unabhängig via AppleScript-Datumsdifferenz, weil macOS-Datumsstrings je nach Spracheinstellung anders aussehen.

Und: vault-drift plus quarantine-reminder sind raus. Obsidian-Altlast, nicht mehr nötig.

Augen

vision.js. Ein neues Tool: vision_lookAtScreen({question, scope}).

VINCI macht via screencapture einen Screenshot des ganzen Screens oder des aktiven Fensters, schickt ihn direkt an Gemini Flash multimodal, bekommt eine Text-Antwort zurück. Der Screenshot wird sofort gelöscht, nie gespeichert.

„Was steht in dem Fenster rechts?“ funktioniert jetzt.

Hände

control.js. Das ist das Modul, bei dem ich am längsten über die Permission-Architektur nachgedacht habe.

VINCI kann jetzt: Apps öffnen und beenden, URLs öffnen (via macOS open, braucht keine Automation-Freigabe), Dateien lesen, schreiben, verschieben, löschen, AppleScript und Shell-Kommandos ausführen, und UI-Automation: Tippen, Tastenkürzel senden, Klicken.

Das ist eine Menge Macht für eine App, die auf meinem persönlichen Mac läuft.

Die Permission-Schicht: warum das nicht optional ist

_permissions.js ist der Kern, über den ich mir die meisten Gedanken gemacht habe.

Alles ist default AUS. 5 Fähigkeiten einzeln schaltbar im neuen Settings-Tab „Steuerung“: apps, files, scripting, uiAutomation, vision.

Riskante Aktionen triggern einen nativen macOS-Bestätigungsdialog (dialog.showMessageBox). Der ist abschaltbar über confirmRisky, aber default an.

Datei-Operationen sind auf eine fileRoots-Allowlist beschränkt. Und hier ist der Part, der beim Code-Review wichtig war: pathAllowed löst Symlinks via realpath auf, bevor es gegen die Allowlist prüft. Ohne das kann ein Symlink in einem erlaubten Ordner auf einen beliebigen Pfad außerhalb zeigen. Das wäre ein klarer Allowlist-Ausbruch. Mit realpath nicht möglich. Regressionstest vorhanden.

Der Confirm-Dialog ist fail-safe gebaut: jeder Fehler, jedes fehlende Fenster führt zu Ablehnen. Nie fail-open.

osaEscape strippt Newlines aus App-Namen und getipptem Text, bevor sie in AppleScript-Strings landen. Newlines können AppleScript-Statements vorzeitig beenden und neue beginnen. Das ist eine klassische Injections-Oberfläche, die man einmal schließen muss.

Audit-Log läuft über die Telemetry mit drei States pro Aktion: allowed, blocked, denied.

Was 325 Tests tatsächlich bedeuten

Das klingt nach einer Zahl die man hinschreibt. Aber hinter den 325 Tests sind 6 Regression-Sentinels, die ich besonders mag, weil sie spezifische Bugs reproduzieren, die ich live erlebt habe.

sentinel-geminiToolMerge: Forced Tools müssen immer eine Subset der deklaratierten Tool-Declarations sein. Wenn nicht, gibt Gemini einen 400-Fehler zurück. Dieser Sentinel fängt das ab, bevor es im Briefing-Button live crasht.

sentinel-calendarGracefulError: Der Calendar-Code darf nie werfen. Er gibt {events: [], error} zurück, und der Briefing-Agent rendert das ehrlich als „Kalender nicht erreichbar“, nicht als leere Terminliste.

sentinel-noUTCTimestamps: Verbietet new Date().toISOString() in 13 user-sichtbaren Modulen. Alle lokalen Zeitstempel gehen über _localTime.js mit Vienna-Offset und DST-Awareness. Wer eine solche Zeile einbaut, bekommt sofort roten Build.

Der Calendar-Daemon hat im Dev-Modus AppleScript jede 2 Minuten ohne TCC-Permission aufgerufen und dabei tccd CPU-Spitzen verursacht. Proactive-Daemons schalten sich jetzt nach 3 aufeinanderfolgenden Fehlern selbst ab bis zum App-Restart.

JARVIS-Level: 75 Prozent

J1 bis J5 sind vollständig live. J6 (Sub-Agents) ist in Stufe 0 bis 4 fertig: Job-Queue mit persistentem JSON-Store, Lifecycle-Management, Concurrency-Limit, Event-System, Researcher-Agent, Briefing-Agent, Weekly-Review.

Offen: J6 Stufe 5 (Vault-Curator), J7 (Pattern-Learning), J8 (Wake-Word „VINCI“).

Ich bin mir nicht sicher, in welcher Reihenfolge ich die angehe. Wake-Word reizt mich sehr, weil es den Hotkey ersetzt und die Interaktion natürlicher macht. Porcupine von Picovoice ist mein Favorit für die Engine, weil Custom-Wake-Word ohne Training möglich ist und die Integration in Electron-Subprocess überschaubar bleibt. Aber das ist noch nicht entschieden.

Was mich dabei überrascht hat

Ich hätte gedacht, die Outline-Migration wäre der schwierigste Teil dieses Builds. War sie nicht.

Der schwierigste Teil war, die Memory-Worker-Extraktions-Logik so zu tunen, dass tainted Inhalte zuverlässig rausgefiltert werden, ohne dass echte Fakten verschwinden. Die Grenze ist feiner als sie aussieht. „VINCI hat Gemini Flash als Haupt-LLM“ ist ein Fakt. „Gemini Flash antwortet manchmal mit 0 Content-Parts“ ist System-Noise. Der Unterschied liegt nicht im Format des Satzes, sondern im Kontext, aus dem er stammt.

stripSystemNoise entfernt jetzt CPU-, RAM-, und Akku-Zeilen aus der Konversation, bevor der LLM sie überhaupt sieht. Der Memworker extrahiert auf einem bereinigten Konversations-Snapshot. Das klingt einfach. Bis man realisiert, wie viele verschiedene Formate System-Output haben kann.

Das Repo ist weiter privat und wird es auch bleiben. Das DMG hat 118 MB, kein Code-Signing (Gatekeeper-Warning beim ersten Start ist bekannt und gewollt, bis ich das Apple-Developer-Zertifikat hole).

Du kannst warten, bis VINCI fertig ist. Aber ich glaube nicht, dass es ein „fertig“ geben wird.