Ich baue VINCI seit Jänner 2026 für mich. Das war immer der Plan: ein Tool für einen Nutzer, auf einem Server, unter meiner Kontrolle. Kein SaaS, kein Abo, keine fremden Daten in einer Cloud, die ich nicht kenne.
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.jsmitrequireCapability()undpathAllowed()aus v2.4.0telemetry.jsmitlogEvent()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.
