Arslan, erklärt.Entwurf, Umsetzung und Entwicklung vom ersten Prototyp bis v0.1.63

01 / ProjektüberblickVon natürlicher Sprache zu konkreter Arbeit

Arslan ist ein quelloffener persönlicher KI-Assistent, der vorrangig für den Mac entwickelt wurde und lokal arbeitet. Nutzer beschreiben eine Aufgabe; Arslan stellt den Kontext zusammen, ruft das Modell auf, setzt Werkzeuge ein, protokolliert die Ausführung und liefert überprüfbare Antworten oder Dateien. Chat, Gedächtnis, Dateiverarbeitung, Terminal, Web, die Bedienung ausgewählter nativer Apps und Hintergrundaufgaben sind über einen gemeinsamen Einstieg zugänglich.

Der Autor entwickelt und erweitert das Projekt allein mithilfe von KI – eine Arbeitsweise, die häufig als Vibe Coding bezeichnet wird. Dieses Dokument führt von den Produktzielen bis zu den konkreten Grenzen im Code: Es erläutert die Entwurfsentscheidungen, die Funktionsweise und die Entwicklung vom ersten Prototyp bis zu v0.1.63.

Ein Einstieg für unterschiedliche Aufgaben

Was „lokal zuerst“ konkret bedeutet

„Lokal zuerst“ beschreibt den primären Speicher- und Ausführungsort: Desktopoberfläche, lokaler Dienst, Datenbank, Arbeitsbereich und Mac-Werkzeuge laufen überwiegend auf dem Rechner des Nutzers. Das Modell wird vom Nutzer konfiguriert. Bei Cloud-Modellen gehen die im Aufruf enthaltenen Gespräche, Dokumentausschnitte und freigegebenen Erinnerungen an den jeweiligen Modellanbieter. Auch kompatible lokale Modellendpunkte lassen sich anbinden; deren Werkzeugaufrufe und visuelle Fähigkeiten hängen jedoch vom Modell und der Implementierung des Dienstes ab.

Die Architektur muss daher zwei Fragen getrennt beantworten: Auf welchem Rechner findet die Arbeit statt, und welche Inhalte werden an welchen Modellendpunkt gesendet? Lokale Datenspeicherung, die Freigabe von Erinnerungen für die Cloud und Werkzeugberechtigungen erfüllen unterschiedliche Aufgaben. Ein einzelner Schalter „lokal“ kann sie nicht zusammenfassen.

Auf welche Version sich dieses Dokument bezieht

Grundlage ist die offiziell veröffentlichte v0.1.63 vom 27. Oktober 2026 um 22:26:31 Uhr Pekinger Zeit (UTC+8); der Abgleich reicht bis zum 27. Oktober 2026. Codelinks verweisen fest auf den Release-Commit 9bbb6ad653b4. Entwicklungen nach der Veröffentlichung, historische Funktionen und künftige technische Arbeiten werden gesondert gekennzeichnet.

Einstieg in die Implementierung: Einheitlicher Einstieg von Arslan; Kontext für Aufgaben und Erinnerungsnutzung; Modellanbindung; Release Notes zu v0.1.63.

02 / Eigenständige Entwicklung und Open SourceEine Person entwickelt mit KI eine App zum System

Arslan ist ein Projekt, das ich allein mithilfe von KI entwickelt habe – häufig wird das als Vibe Coding bezeichnet. Vom ersten Prototyp bis zu den späteren Versionen habe ich das Projekt durchgehend eigenständig vorangetrieben.

„Eigenständige Entwicklung“ bedeutet hier, dass der Autor das gesamte Projekt allein verantwortet und vorantreibt; KI dient als Werkzeug bei der Umsetzung. Zugleich baut Arslan auf quelloffenen Frameworks, System-APIs, externen Modellen und Komponenten Dritter auf. Arbeitsweise, Projektverantwortung und Herkunft der Komponenten sind klar voneinander zu unterscheiden. Im Folgenden geht es um die Entwürfe und Implementierungen, die tatsächlich in das Produkt eingeflossen sind.

Von generiertem Code zu einem wartbaren Produkt

Lauffähiger Code deckt nur einen kleinen Teil eines Produkts ab. Eine Desktop-App muss auch klären, wie Dienste starten, Fenster sich verbinden, alte Datenbanken aktualisiert werden, nach dem Beenden von Prozessen aufgeräumt wird, wer die Systemberechtigungen hält und ob das Installationspaket auf einem Rechner ohne Entwicklungsumgebung funktioniert. Ein Agent bringt weitere Unsicherheiten mit: Modellaufrufe können das Zeitlimit überschreiten, Werkzeugparameter abgeschnitten werden, Webseiten unvollständig lesbar sein. Auch mitten in der Ausführung kann eine Freigabe durch den Nutzer erforderlich werden.

Diese Probleme haben die Weiterentwicklung von Arslan schrittweise in vier Richtungen gelenkt: klare Verträge für Eingaben und Zustände, beobachtbare Werkzeugergebnisse zur Prüfung der Fertigstellung, Berechtigungsgrenzen für tatsächliche Nebenwirkungen sowie Tests und Abnahmeprüfungen für Änderungen und Releases. KI-Unterstützung kann Umsetzung und Fehlersuche beschleunigen; ein verlässlich auslieferbares Produkt benötigt jedoch das Zusammenspiel dieser Vorkehrungen.

Was Arslan selbst leistet und was Abhängigkeiten beitragen

Das Projekt ist unter Apache-2.0 veröffentlicht. Lizenzen und Urheberschaft von Drittkomponenten sind in THIRD_PARTY_NOTICES.md aufgeführt, das auch mit der App ausgeliefert wird; dort steht auch Hermes Agent (MIT), auf dem Arslans Lesen von Shell-Befehlen beruht. Der offene Quellcode macht Implementierung, Grenzen und Entwicklung nachvollziehbar; damit gehört auch die Begründung von Entscheidungen zur Dokumentation.

Die Angaben zur Arbeitsweise stammen vom Autor. Implementierung und Urheberschaft: Projektlizenz; Hinweise zu Drittkomponenten; Architekturentscheidung zum Laufzeitkern; Umbau zur einheitlichen Schleife.

03 / Technologie-StackAufgabenteilung zwischen Oberfläche, Host, Ausführung und Daten

Arslans Technologie-Stack folgt den Anforderungen einer Desktopanwendung und eines persönlichen Agenten. Die genauen Versionen unten stammen aus den Lockdateien von v0.1.63 und geben die für diesen Quellstand aufgelösten Abhängigkeiten wieder. Sie sind weder die Versionsnummern, die Nutzer auf ihrem Rechner installieren müssen, noch die Release-Version des Projekts.

Warum der Ausführungskern in Python bleibt

Python übernimmt Modellanbindung, Dokumentverarbeitung, Agent-Schleife und Aufgabendienste. Dabei lassen sich das vorhandene Ökosystem und bestehende Implementierungen direkt weiterverwenden. Tauri und Rust verantworten Fenster, Prozesslebenszyklus und native Integration. Eine öffentliche Architekturentscheidung dokumentiert die Beibehaltung dieses Kerns. Ein Wechsel in eine andere Sprache würde zugleich Werkzeuge, Datenmigrationen, Paketierung und Testgrenzen verändern; der Nutzen lässt sich nicht allein daran messen, ob eine Lösung „nativer“ ist.

Die Struktur ist logisch geschichtet, bleibt bei der Bereitstellung aber auf den lokalen Dienst konzentriert. Die internen Python-Module sind keine jeweils eigenständigen entfernten Microservices. Auch Redis, Celery, Docker oder Kubernetes sind für den Betrieb nicht erforderlich. Hands, Bridge, MCP-Dienste und Terminal-Unterprozesse bilden dort Prozessgrenzen, wo getrennte Berechtigungen oder eigene Laufzeitumgebungen benötigt werden.

Festgeschriebene Abhängigkeiten: Frontend-Lockdatei; Desktop-Lockdatei; Python-Lockdatei. Entwurf und Urheberschaft: Entscheidung zum Laufzeitkern; Hinweise zu Drittkomponenten.

04 / Wie das Projekt seinen heutigen Stand erreichteVon generierten Experten zu einem dauerhaft arbeitsfähigen Arslan

Der Autor entwickelt Arslan kontinuierlich allein und mit KI-Unterstützung im Sinne von Vibe Coding. Diese Entwicklung umfasst neue Fähigkeiten ebenso wie zurückgenommene Entwürfe: Manche Funktionen benötigen ergänzende Betriebsbedingungen, manche Komplexität muss entfallen. Diese Veränderungen erklären die heutige Architektur besser als eine undifferenzierte Liste aller jemals vorhandenen Funktionen.

Juni: Ein geschlossener Ablauf für „Agenten per Gespräch erstellen“

Der früheste erhaltene Commit vom 7. Juni 2026 beginnt mit Datenmodellen. Damals verfolgte das Projekt einen Meta-Agent-Ansatz: Auch technisch unerfahrene Nutzer sollten im Gespräch Fachexperten erstellen können, die anschließend Aufgaben erledigen. Es folgten Modelladapter, Werkzeugregister, ein Zustandsautomat für die Anforderungsklärung, Vorlagen, Spawn Manager und CLI. Am 8. Juni wurden FastAPI, asynchrone Datenbank, Authentifizierung, WebSocket und React-Oberfläche verbunden. Der Prototyp besaß damit einen interaktiven Einstieg mit Speicherung und Wiederherstellung der Verbindung.

Als Werkzeuge tatsächlich ausgeführt wurden, musste das System nachvollziehen können, „was ausgeführt wurde“, und Antworten mit Material versorgen. Am 23. Juni kamen Runs, Steps, Evaluations sowie Dokumentaufteilung und SQLite FTS5 hinzu; am 27. Juni folgten die MCP-Transporte stdio und HTTP. Damit entwickelte sich das Projekt vom Erzeugen eines Expertenprompts zur Verwaltung eines vollständigen Ablaufs: Modell aufrufen, Werkzeuge ausführen, Verlauf speichern, Unterlagen durchsuchen und Ergebnisse an den Nutzer zurückgeben.

Erstes Datenmodell; Runs-Datenmodell; FTS5-Wissensindex; MCP-HTTP-Transport.

Juli: Gedächtnis und Auslieferung als technische Aufgaben

Am 5. Juli erhielt Second Brain Embeddings und eine nach Geltungsbereichen gefilterte hybride Suche, die Volltextsuche, Vektorähnlichkeit und RRF-Rangfusion kombiniert. Danach kamen Herkunft von Fakten, Gültigkeitsstatus, Ersetzung und Widerruf, Ordnungsvorschläge sowie Nutzungsaufzeichnungen hinzu. Das Gedächtnis wurde damit mehr als eine Gesprächszusammenfassung: Relevanz, fortbestehende Gültigkeit und Geltungsbereich einer Information bestimmen mit, ob sie in den Modellkontext gelangen darf.

Mehr Verlauf im Kontext bringt neue Abwägungen mit sich. Ein zu großer Suchbereich kann irrelevantes Material einbeziehen, alte Fakten können neuere überlagern, und externe Texte können langfristiges Verhalten beeinflussen. Deshalb ergänzte die Implementierung im Juli Herkunft und zeitliche Einordnung der Fakten, unterschied zwischen automatischen Ergänzungen, prüfpflichtigen Änderungen und sensiblen Inhalten und führte Ordnungsergebnisse einem Vorschlagseingang zu. Die späteren Gedächtnisfunktionen entwickelten diese Regeln weiter. Dass Nutzer Erinnerungen sehen, korrigieren und zurücknehmen können, wurde zum konkreteren technischen Ziel als bloß „mehr behalten“.

In dieser Phase begann auch die Arbeit an langfristiger Wartbarkeit. Am 14. Juli wechselten Datenbankmigrationen zu einem eigenen versionierten Runner; die Alembic-Abhängigkeit entfiel. Am 10. Juli wechselte die Lizenz zu Apache-2.0, und NOTICE sowie SECURITY.md kamen hinzu; ein ausdrücklicher Commit zur Open-Source-Vorbereitung folgte am 25. Juli. Am 27. Juli erschien v0.1.0 als erste installierbare Desktopversion. Tauri-Hülle und gebündeltes Python-Backend wurden gemeinsam ausgeliefert; Signierung, Notarisierung, Updates und Prüfungen der Erstinstallation wurden Teil des Release-Ablaufs.

Die tatsächliche Installationsumgebung zeigte unmittelbar Lücken, die Entwicklungstests nicht erfasst hatten: In den Paketen v0.1.0–0.1.6 fehlte eine WebSocket-Laufzeitabhängigkeit. Der Health-Endpunkt funktionierte, der Chat konnte jedoch keine Verbindung aufbauen. 0.1.7 korrigierte die Abhängigkeitsebene und die impliziten PyInstaller-Importe und nahm einen echten Handshake in die Installationsabnahme auf. Der Fehler zeigt, warum auf „das Backend ist gestartet“ die Prüfung folgen muss, ob der gesamte Nutzerablauf funktioniert.

Hybride Suche; Versionierte Migrationen; Open-Source-Vorbereitung; Rückblick auf den WebSocket-Fehler im Installationspaket.

August: Fähigkeiten anbinden und verständlich machen

0.1.20 unterschied bei Zugangsdaten zwischen nicht konfiguriert, entschlüsselbar und nicht entschlüsselbar und stabilisierte Salt sowie Schlüsselmigration. Die Suche erhielt Quellen- und Fehlerangaben, Modelle wurden nach Aufgaben aufgeteilt. Es folgten MCP OAuth, OpenRouter-Anmeldung, Ersteinrichtung, Erweiterungsmanifeste, Lesen und Schreiben im lokalen Arbeitsbereich, geplante Aufgaben und SSH. Mit der Zahl der Erweiterungen wuchs auch die Pflicht, ihren Zustand präzise zu erklären: Kann die aktuelle Verbindung Werkzeuge aufrufen, ist die Ausstattung aktiv und welche Aktion benötigt eine Freigabe?

Auch die lokale Ausführung wurde stärker unterteilt. Lesen und Schreiben im Arbeitsbereich wurden getrennt; Schreiben benötigt die passende Berechtigung. Geplante Aufgaben besitzen eine eigene Planungserlaubnis. SSH kann Rechner speichern, verlangt aber weiterhin für jede entfernte Ausführung eine Bestätigung. Das Werkzeugverzeichnis beschreibt damit Fähigkeiten und Nutzungsvoraussetzungen zugleich. „Verbunden“ und „darf jetzt ausgeführt werden“ sind für Nutzer unterschiedliche Zustände, die sowohl Oberfläche als auch Modellkontext abbilden müssen.

Das Turn Journal von 0.1.23 erlaubte, eine noch entstehende Antwort nach einem Gesprächswechsel wieder aufzunehmen. Die Korrektur der npx-Erkennung in der installierten App zeigte erneut, dass eine Desktopanwendung eine andere Umgebung vorfindet als ein Terminal. Im August ging es deshalb nicht nur um zusätzliche Dienste, sondern darum, Verbindungen, Zustände und Berechtigungen in verständliche Bedienabläufe zu übersetzen.

September: Von einzelnen Antworten zu nachvollziehbarer Arbeit

0.1.38 konzentrierte sich auf Zuverlässigkeit: eine bei Unsicherheit sperrende Python-Sandbox, eine eigenständige Rechenlaufzeit, persistente Runs, Artefakte, Checkpoints und ein gemeinsames Ausführungsbudget. Vorabversionen und Stabilisierung von 0.1.40 ergänzten Projektgedächtnis, Dokumentquellen, Aufgabenfortsetzung und Sicherungen vor Migrationen. Bekannte Fehler bei sprachübergreifenden Vergleichen mehrerer Dokumente blieben dokumentiert. Anklickbare Quellen belegen, dass Material auffindbar ist; sie beweisen nicht die Richtigkeit der Modellschlussfolgerung.

Etwas früher, vom 31. August bis zum 3. September, entwickelte sich die Sprachfunktion vom Vorlesen (0.1.32) über Push-to-Talk (0.1.36) zum Halbduplexgespräch (0.1.37); zugleich wurden Mikrofonberechtigungen und Sprachauswahl korrigiert. Die Rechercheabnahme von 0.1.40 stellte fehlgeschlagene sprachübergreifende Vergleiche weiterhin als Fehler dar. Die Quellenprüfung von 0.1.41 blieb nach unzureichender Kalibrierung standardmäßig ausgeschaltet (0.1.63 hat diese Recherchenprüfung später entfernt). Solche Aufzeichnungen grenzen ein, was „das System hat geprüft“ bedeutet, und richten weitere Verbesserungen auf tatsächliche Fehler aus.

Mit 0.1.41 ließ das Schließen des Fensters die App in der Menüleiste weiterlaufen. 0.1.42 verlagerte lange Aufgaben in den Hintergrund, damit Nutzer weiterchatten können. 0.1.43 unterschied anschließend zwischen weicher Budgetgrenze und hartem Stopp: An der weichen Grenze wird zunächst mit dem bereits vorliegenden Material ein Ergebnis erstellt, damit eine halb fertige Recherche nicht ohne Lieferung endet. Aufgaben erhielten zunehmend einen vom Fenster unabhängigen Lebenszyklus. Daraus folgt jedoch nicht, dass beliebige externe Aktionen nach einem Absturz sicher automatisch wiederholt werden können.

Ende September bis Oktober: Eine gemeinsame Ausführungsschleife

Im frühen Entwurf waren Experten dauerhafte Rollen. Nutzer und System mussten Auswahl, Einladung und Routing verwalten. 0.1.44 beendete das Erstellen und Einplanen von Experten; ihre bisherigen Methoden ließen sich in Skills umwandeln. 0.1.46 stoppte die Expertenweiterentwicklung im Hintergrund, für die es keinen aktiven Nutzungspfad mehr gab. 0.1.48 entfernte den vorgeschalteten Router: Jede Nachricht gelangt unmittelbar in die Agent-Schleife. Laut Release Notes stammten manche fest vorgegebenen „Das kann ich nicht“-Antworten aus Routingentscheidungen und spiegelten keine tatsächliche Fähigkeitsgrenze wider. Mit dieser Zusammenführung kehrte die Werkzeugauswahl in den Ausführungsprozess zurück, der die realen Werkzeuge und Zustände kennt.

Danach konzentrierten sich die Verbesserungen auf die gemeinsame Ausführungsebene: 0.1.49 verbesserte native Werkzeugprotokolle sowie den Umgang mit abgeschnittenen Antworten und Fehlern. 0.1.50 ergänzte den aktuellen Arbeitszustand, Pläne und alternative Vorgehensweisen. 0.1.51 führte Befehlssandbox und Island ein. Mit 0.1.52 flossen Nutzererinnerungen und Learned Practices in spätere Arbeit ein. „Lernen“ bedeutet hier, verwaltbare Erfahrungen zu speichern und zu verwenden; die Gewichte des Basismodells werden nicht verändert.

0.1.53 ergänzte einen eigenständigen Hands-Helper zum Lesen des Bedienungshilfenbaums und Bedienen von Mac-Apps sowie die Mac-Seite der iPhone Bridge. 0.1.54 macht diese Mac-Seite bereit für die iPhone-App (Freigaben per Touch ID, ein Eintrag pro Telefon, Aufräumen beim Entfernen eines Telefons) und schließt vier Lücken im Terminal-Gate; jede dieser Änderungen führt zu mehr Rückfragen, nicht zu weniger. 0.1.55 gibt allem, was eine Rückfrage stellt, ein einheitliches Erscheinungsbild und eine gemeinsame Warteschlange: Karten lassen sich im Posteingang beantworten und, sofern der Schritt nicht riskant ist, auch in der Island. 0.1.56 bringt Projekte in zwei Ebenen: ein Board für alle Projekte und für jedes Projekt Etappen mit Prüfpunkten, die Arslan nur anhand von Belegen abhakt, die es benennen kann. 0.1.57 lässt die Fähigkeiten wachsen: Braucht ein Schritt etwas, das Arslan nicht kann, sucht es einen passenden Server oder Skill, fragt nach, installiert ihn fest versioniert und in einer Sandbox, testet ihn und wiederholt den Schritt. 0.1.58 macht Antworten und Dateien lesbar: eine unaufdringliche Zeile zu dem, was getan wurde, Dateien, die als Karten zurückkommen, eine Leseansicht und jedes beliebige Modell pro Unterhaltung. 0.1.59 hält den Chat auch bei langen Antworten am Leben, antwortet in der Sprache des Nutzers und wertet abgeschlossene Hintergrundarbeit als erledigt. 0.1.60 bringt Hands v2: Es kann das eine Fenster ansehen, in dem es arbeitet, sich kurz den Vordergrund ausleihen und – nur nach einem Ja – den Bildschirm übernehmen. 0.1.61 bringt eine einheitliche Freigabekarte für das Chatfenster, den Posteingang, die Island und das iPhone, MCP-Server, die sich selbst starten, und eine Korrektur für Claude-Modelle, die die Einstellung temperature ablehnen. 0.1.62 lässt lange Terminalbefehle bis zu ihrer eigenen Grenze laufen, beschränkt „braucht Ihre Prüfung“ auf Aktionen, die tatsächlich eine Spur hinterlassen haben könnten, formt MCP-Werkzeugbeschreibungen so um, dass die Ablehnung eines Anbieters nicht mehr jeden Chat zum Scheitern bringt, und verhindert, dass Dateischreibvorgänge einem Link aus dem Arbeitsordner hinaus folgen. 0.1.63 erlaubt es, eine Nachricht hinzuzufügen, während eine Antwort läuft, streamt Antworten, während sie geschrieben werden, führt bis zu vier Lesevorgänge gleichzeitig aus, speichert einen Kontrollpunkt, damit ein Zug rückgängig gemacht werden kann, sendet selten genutzte Werkzeuge nur bei Bedarf, ergänzt ein Dollar-Limit pro Aufgabe (standardmäßig eingeschaltet) und fragt bei jedem neuen Befehl nach, während die Beurteilung harmloser Befehle erst später vervollständigt wird. Außerdem wurde Code gelöscht: der Code aus der Expertenzeit, den keine Antwort mehr erreichen konnte, die Evolutions- und Kurationsmaschinerie, die Recherchenprüfung, „Destillieren“, der Docker-Bereitstellungsweg und die mitgelieferte Hermes-Kopie. Die frühere Expertenorchestrierung ist inzwischen historisch. Auch der Zugriff über Bedienungshilfen bedeutet nicht, dass jede App zuverlässig steuerbar wäre. Die aktuelle Version begrenzt das tatsächlich ausführbare Handeln des Modells weiterhin durch sichtbare Zustände, ausdrückliche Berechtigungen und überprüfbare Ergebnisse.

Grundlagen der Zuverlässigkeit; Umfang des stabilen Rechercheassistenten; Hintergrundarbeit; Einheitliche Agent-Schleife; Hands und Bridge.

05 / SystemarchitekturDie Aufgaben von Oberfläche, Ausführung und Berechtigungen

Einfach ausgedrückt: React ist die sichtbare Arbeitsoberfläche, Tauri die Verbindung zu macOS, Python die koordinierende Ausführungsengine. Das Modell trifft Entscheidungen, Werkzeuge führen tatsächliche Aktionen aus, Datenbank und Dateisystem speichern Verlauf und Ergebnisse. Diese Aufgaben gehören zu einem gemeinsamen Desktopprodukt, aber nicht zu einem einzigen Prozess.

Warum diese Aufteilung gewählt wurde

Wie die Prozesse beim Start verbunden werden

1. Tauri startet den gebündelten Python-Sidecar und zeigt bis zur Dienstbereitschaft einen Startbildschirm.
2. Der Sidecar bindet bevorzugt den lokalen Port 47317. Bei einem Konflikt nutzt er einen temporären Port und meldet ihn über die Standardausgabe im ARSLAN_PORT-Handshake zurück.
3. Nach Empfang des Ports lädt der Desktop-Host im System-WebView die vom lokalen Dienst bereitgestellte React-Seite. Der bevorzugte feste Port hält WebKit-Origin und lokalen Oberflächenspeicher möglichst stabil. Ein serverseitiges Sitzungsverzeichnis ermöglicht, den Verlauf auch nach einem Portwechsel wiederzufinden.
4. Die Oberfläche verwaltet Ressourcen über HTTP und empfängt Textstreams, Werkzeugzustände, Freigaben und Aufgabenfortschritt über WebSocket. Auch lokale Verbindungen benötigen Token- und Herkunftsprüfungen; der Server der Desktop-App verlangt stets seinen Token, akzeptiert keine andere Website als Aufrufer und ignoriert Einstellungen, die aus der startenden Umgebung geerbt wurden.
5. Der Host hält die Standardeingabe-Pipe als Lebenszyklusverbindung offen. Beendet sich der Elternprozess und entsteht EOF, kann der Sidecar aufräumen und enden. Auch die Ausgabepipes müssen fortlaufend gelesen werden, um Blockaden oder verwaiste Prozesse nach Verbindungsverlust zu vermeiden.

Gemeinsam halten diese Details die Lebenszyklen von Fenster, Dienst und Datenbank im Einklang. Ein erfolgreicher HTTP-Health-Aufruf beweist nicht, dass WebSocket, Anhänge, statische Ressourcen und native Helper einsatzbereit sind. Sie benötigen eigene Prüfungen in der Release-Abnahme.

Startdetails: Einstieg des gebündelten Dienstes und Portstrategie; Sidecar-Handshake und Pipe-Verwaltung; WebSocket-Anbindung.

Alte und neue Architektur: Wiederverwendung bleibt, Expertenrouting entfällt

„Einheitliche Schleife“ bedeutet weder, dass alles seriell abläuft, noch dass niemals delegiert wird. Der Code enthält weiterhin eingeschränkte Worker mit ausschließlich lesendem Zugriff. Sie sind nicht mit dem früheren Expertensystem samt eigener Persönlichkeit, Ausstattung, Weiterentwicklung und Routing gleichzusetzen.

Einstiege in den Code: Desktop-Host und Sidecar-Lebenszyklus; Einheitlicher Einstieg; Ausführungsschleife; Entscheidung für den bestehenden Python-Ausführungskern; Überwachung des Bridge-Prozesses; Lokaler Bridge-Steuerkanal; Geräteübergreifendes Protokoll.

06 / AusführungslaufzeitJede Anfrage braucht einen Ablauf, Grenzen und ein Ergebnis

Arslans Ausführungskern übersetzt die Absicht des Nutzers in beobachtbare Schritte: Kontext vorbereiten, Modell aufrufen, Werkzeuganfragen prüfen, erlaubte Aktionen ausführen, tatsächliche Ergebnisse lesen und anschließend fortfahren oder liefern. Seit v0.1.60 verwendet der Standardeinstieg eine einheitliche Schleife; Nachrichten gelangen direkt in den Antwortablauf, und dauerhafte Fakten werden erst nach der Antwort extrahiert. Der Hauptablauf beginnt nicht mit einem Modellrouting-Aufruf, und der Code aus der Expertenzeit, den keine Antwort mehr erreichen konnte (Anlegen von Experten, ihre Vorlagen und die Engine), wurde in v0.1.63 entfernt.

Quellcode: Nachrichteneingang und Kontextaufbau; Vertrauenswürdiger Aufgabenkontext; Einheitliche Werkzeugschleife.

Das Modell schlägt den nächsten Schritt vor, die Laufzeit prüft seine Voraussetzungen

Das Modell sieht Werkzeuge als Namen, Verwendungszweck und Parameterschema. Gibt es strukturierte tool_calls zurück, parst die Laufzeit zunächst JSON und validiert die Parameter. Danach prüft sie erneut, ob das Werkzeug noch verfügbar ist, das aktuelle Budget den Aufruf erlaubt und eine Nutzerfreigabe erforderlich ist. Das Register ordnet integrierten Werkzeugen ihre Ausführungsfunktionen zu; Werkzeuge mit dem Präfix mcp_ werden an MCP weitergeleitet, und dem Modell werden nur MCP-Server angeboten, die gerade bereit sind. Ein Eintrag im Register bedeutet nicht, dass das Werkzeug in jeder Gesprächsrunde angeboten wird: Seit v0.1.63 enthält eine Anfrage nur die regelmäßig genutzten Werkzeuge plus zwei Finder, find_tools und use_tool; selten genutzte Werkzeuge und MCP-Werkzeuge werden bei Bedarf gefunden und aufgerufen, mit denselben Freigaben und Aufzeichnungen wie bei einem direkten Aufruf. Die Liste, die eine Unterhaltung bei Bedarf genutzt hat, wächst auf höchstens 12 und wird nur im Arbeitsspeicher gehalten.

Eine entscheidende Grenze ist die Vollständigkeit der Antwort. Schneidet der Anbieter einen Werkzeugaufruf wegen eines Ausgabelimits ab, wird die gesamte betreffende Gruppe von Aufrufen nicht ausgeführt – auch wenn ein einzelner Aufruf vollständig erscheint. Modelltext, der Werkzeugaufrufe begleitet, gilt nur als Zwischenbericht und darf nicht vorzeitig als Endergebnis dienen. Vor und nach der Ausführung werden Checkpoints gespeichert; tatsächliche Werkzeugergebnisse gehen mit der zugehörigen Aufrufidentität an das Modell zurück. Inhalte aus Webseiten, Dateien und externen Werkzeugen bleiben dabei Daten.

„Ich habe die Datei gespeichert“ muss sich deshalb einem tatsächlichen Speicherergebnis und einem Artefaktverweis zuordnen lassen. Ein sprachliches Versprechen wird nicht automatisch zu einer ausgeführten Aktion. Auch Werkzeugfehler fließen in die nächste Eingabe ein. Die Schleife kann ihre Vorgehensweise ändern, muss dabei aber dieselben Berechtigungs- und Budgetgrenzen einhalten.

Bei „Lies das angegebene Verzeichnis und erstelle eine Übersicht“ wird etwa der Verzeichnispfad zunächst als Eingabe in den Aufgabenumfang aufgenommen. Das Modell fordert das Lesen an; das Werkzeug liefert reale Dateiinformationen. Erst darauf lässt sich die Übersicht stützen. Sollen Dateien anschließend verschoben oder gelöscht werden, muss die Laufzeit die Freigabe für die jeweilige Operation beurteilen. Die Lieferung sollte auf eine tatsächlich erzeugte Datei verweisen und die Prüfergebnisse nennen. Dateiliste, Aktionsbeleg und Artefaktverweis erfüllen in diesem Ablauf jeweils unterschiedliche Nachweisfunktionen.

Seit v0.1.63 erscheint die Antwort so, wie sie geschrieben wird (auf den unten aufgeführten Endpunkten); Prüfungen, die eine Antwort früher zurückgehalten haben, ergänzen bei Bedarf danach eine Korrektur. Bricht ein Stream auf halbem Weg ab, behält Arslan, was Sie gesehen haben, und sagt, dass die Antwort unterbrochen wurde, statt von vorn zu beginnen. Verlangt das Modell mehrere Lesevorgänge hintereinander (Webseiten, Suchen, MCP-Werkzeuge, die ihr Server als nur lesend kennzeichnet), laufen bis zu vier gleichzeitig; jedes Ergebnis bleibt dem Aufruf zugeordnet, der es angefordert hat, und jeder Aufruf, der kein Lesevorgang ist, läuft allein an seiner Stelle.

Quellcode: gemeinsam laufende Lesevorgänge; Streaming und Werkzeugschleife.

Einheitlicher Einstieg bei unterschiedlichen Modellprotokollen

LLMAdapter bietet eine gemeinsame Aufrufschnittstelle. Der jeweilige Provider verarbeitet Anfrageformat, Streaming-Ereignisse, Werkzeugaufrufe und usage. Provider-Implementierungen senden HTTP-Anfragen mit httpx; ein OpenAI-kompatibler Endpunkt kann auch auf einen lokalen Modelldienst verweisen. Bei Auswahl eines Cloud-Modells wird der zugehörige Anfragekontext an den vom Nutzer konfigurierten Anbieter gesendet.

Trajectory bezeichnet den strukturierten Ablaufverlauf der Schleife. Er hält fest, welcher Aufruf welches Ergebnis erzeugt hat. So bleiben interne Aufzeichnungen einheitlich, während jeder Anbieter sein eigenes Protokoll verwenden kann. Werkzeuginteraktionen müssen dadurch nicht zu schwer überprüfbarem Fließtext verdichtet werden. Lehnt ein Endpunkt den nativen Verlauf ab, wechselt die Runde für den Rest dieser Runde zur älteren Darstellung.

Auf dieser Ebene sitzen zwei Reparaturen. Seit 0.1.61 sendet Arslan die Anfrage erneut ohne die Einstellung, wenn ein Anbieter eine optionale Anfrageeinstellung ablehnt (zum Beispiel temperature bei neueren Claude-Modellen), oder unter dem Namen, den der Fehler verlangt, und merkt sich das für das Modell bis zum Neustart. Seit 0.1.62 werden MCP-Werkzeugbeschreibungen in eine Form umgeformt, die Anthropic, OpenAI-kompatible Anbieter und Gemini akzeptieren; lehnt ein Anbieter ein Werkzeug trotzdem ab, wird dieses Werkzeug für den Rest der Antwort weggelassen (bei einer zweiten Ablehnung oder einer Ablehnung, die kein Werkzeug nennt, entfallen für diese Antwort alle MCP-Werkzeuge). Integrierte Werkzeuge werden unverändert gesendet.

Quellcode: Modellfassade; Datenstruktur des Ablaufverlaufs; Fähigkeitsvertrag der Provider; erneutes Senden ohne abgelehnte Einstellung; Umformung der MCP-Werkzeugbeschreibungen; Werkzeuge bei Bedarf; Änderungen an der Ausführungsebene.

Temporäre Worker und Hintergrundaufgaben erfüllen unterschiedliche Aufgaben

delegate_work verteilt voneinander unabhängige Recherchen an temporäre Worker: höchstens 4 Aufträge pro Gruppe, davon maximal 2 gleichzeitig. Derzeit dürfen Worker ausschließlich web_search und web_extract verwenden. Sie können weder Dateien noch persönliche Erinnerungen schreiben und nicht rekursiv weiterdelegieren. Der Hauptagent prüft und integriert das zurückgelieferte Material. So bleibt parallele Recherche möglich, während die Ausführungsverantwortung bei der ursprünglichen Aufgabe liegt.

Ein Hintergrund-Job dient dagegen einer längeren vollständigen Aufgabe. Er besitzt eigenen Kontext und eigenes Budget, verwendet dieselbe Werkzeugschleife sowie dieselben Abläufe zur Artefaktprüfung und -reparatur. Seine Fortschrittsmeldungen erscheinen als Aufgabenkarte im Gespräch; standardmäßig laufen höchstens 3 Jobs gleichzeitig. Netzwerkverbindung, Chatfenster und Hintergrundausführung haben eigene Lebenszyklen. Ein Gesprächswechsel bricht keine Aufgabe ab. Bei Ruhezustand oder Prozessende übernimmt jedoch keine Cloud die Hintergrundarbeit.

Vor der harten Grenze beginnt der Abschluss

Das Budget erfasst Modellanfragen, Werkzeugaufrufe, kumulierte Token, Ausführungszeit und seit v0.1.63 auch Dollar. Eine Chat-Antwort und eine Hintergrundaufgabe erhalten nun dieselben Grenzen: die in den Einstellungen gewählte Stufe, standardmäßig standard. An der weichen Grenze (Soft Limit) soll die Schleife die Recherche nicht weiter ausweiten, sondern die vorhandenen Ergebnisse aufbereiten. Die harte Grenze (Hard Limit) verhindert unkontrollierten weiteren Verbrauch. Verschachtelte Ausführungen und Wiederholungen zählen ebenfalls zum Aufgabenbudget. Zusätzlich werden wiederholte Aufrufe ohne Fortschritt erkannt, damit dieselbe fehlgeschlagene Vorgehensweise nicht endlos erneut versucht wird.

Die Tabelle zeigt die standardmäßigen Soft Limits; die vier Hard Limits betragen jeweils das 1.5-Fache. Grenzen für einzelne Ausgaben und Artefaktgrößen werden separat berechnet. Tokenverbrauch wird erst nach Eingang einer Antwort verbucht. Die Schwellen sind daher Steuerungsgrenzen, keine exakten Kostenobergrenzen oder Zusagen zur Fertigstellungszeit. Wartezeit auf eine Freigabekarte zählt nicht als Ausführungszeit. Zusätzlich zu den Stufen gibt es ein Dollar-Limit pro Aufgabe, standardmäßig eingeschaltet bei 2 $ (Einstellungen › Hintergrund › Dollar-Limit pro Aufgabe): Bei zwei Dritteln davon beginnt der Lauf mit dem Abschluss, beim Limit hält er an. Es zählen nur Antworten von Modellen mit bekanntem Preis; ein lokales Modell oder eines, das in der Preistabelle fehlt, trägt nichts bei, und die Token-Limits gelten weiterhin. Die Prüfung erfolgt vor der nächsten Anfrage, ein Lauf kann das Limit also um eine Antwort überschreiten. Fortgesetzte Aufgaben übernehmen bereits verbrauchte Zähler, Ausführungszeit und Dollar. Wartezeit während eines Stillstands zählt nicht als erneute Ausführungszeit und setzt das Budget nicht zurück.

Lange Arbeit bleibt im Chat: Arslan schiebt sie nicht mehr von selbst in den Hintergrund; eine Hintergrundaufgabe ist dieselbe Arbeit an anderer Stelle, wenn Sie oder das Modell sie wählen. Nach zehn Minuten teilt eine Antwort mit, dass sie noch arbeitet. Ein Terminalbefehl läuft so lange, wie er angefordert hat (standardmäßig 2 Minuten, höchstens 10), nie über die Zeit hinaus, die der Antwort bleibt; stoppt ihn ein Zeitlimit, sieht Arslan trotzdem die bisherige Ausgabe und wird darüber informiert, und ein Befehl, der seine Ausgabe überflutet, behält Anfang und Ende. Jeder neue Befehl zeigt standardmäßig zuerst eine Karte (v0.1.63), und eine geplante Aufgabe führt in dieser Version keine Befehle aus: Dieser Schritt wird übersprungen und im Posteingang aufgeführt. Eine unbeantwortete Karte läuft nach 30 Minuten ab; Arslan wird mitgeteilt, dass das keine Ablehnung ist.

Quellcode: Budgetregeln; Zeitlimit und Ausgabegrenze von Befehlen; Freigabekarten und ihr Ablauf; Temporäre Worker; Hintergrundaufgaben.

Aufgabe, Versuch und Abnahme werden getrennt erfasst

TaskSpec speichert die Aufgabenvereinbarung mit Anweisung, Eingaben, Umfang, Abnahmekriterien und Budget sowie einer Revisionsnummer. Ein task kann mehrere attempts durchlaufen; ein attempt ist ein konkreter Ausführungsversuch. Eine geänderte Vereinbarung, verspätete Ergebnisse nach einem Abbruch und neue Versuche nach einer Wiederaufnahme dürfen ihre Zustände nicht gegenseitig überschreiben. Persistente Aktualisierungen prüfen sowohl die attempt-Identität als auch die row version, damit veraltete Ausführungen keine neueren Zustände überschreiben.

Abnahmeergebnisse unterscheiden unter anderem bestanden, fehlgeschlagen, nicht ausgeführt und nicht anwendbar. Eine Bewertung benötigt passende Belege. Vereinbarte Prüfungen dürfen nicht fehlen, und die Bewertung darf nicht ausschließlich auf einer Selbsteinschätzung des Modells beruhen. Dateiexistenz, Aufgabenbezug und Prüfsummen lassen sich deterministisch kontrollieren; für subjektive Qualität kann ergänzend eine Modell- oder menschliche Bewertung sinnvoll sein. Solange Aktionen noch vorbereitet werden, laufen oder eine unbekannte Wirkung haben, verhindert auch die Repository-Schicht einen unmittelbaren Wechsel auf erfolgreich.

Deshalb müssen Aufgabenrevisionen ihre Identität behalten: Ein für frühere Anforderungen erzeugtes Ergebnis belegt nicht automatisch, dass neue Anforderungen erfüllt sind. Eine Abnahme muss sich auf dieselbe Revision der Vereinbarung, denselben gültigen Versuch und zu dieser Aufgabe gehörende Belege beziehen. Wesentliche Prüfungen dürfen nicht beliebig als „nicht anwendbar“ markiert werden; diesen Spielraum gibt es nur für nicht kritische Kriterien gemäß den Vertragsregeln. Fehlen Belege, bleibt das Ergebnis ungeprüft oder unvollständig, bis ergänzende Prüfungen vorliegen.

Wiederaufnahme auf Grundlage vorhandener Belege

Checkpoints speichern Fortschritt, verbrauchtes Budget sowie Verweise auf Belege und Artefakte. Laufzeitereignisse stehen der Oberfläche nach einer Wiederverbindung zur Verfügung. Die prozessinterne Run Registry hält die tatsächlichen asynchronen Aufgaben und Abbruchzugänge und verteilt Ereignisse an verbundene Fenster. Beim erneuten Verbinden werden Snapshot und Anbindung an den Ereignisstrom synchron vorgenommen, um verlorene oder doppelte Ereignisse am Übergang zu vermeiden.

Nach einem Prozessneustart werden nicht beendete Ausführungen als unterbrochen erkannt; Nutzer müssen sie ausdrücklich fortsetzen. Wurde eine externe Aktion bereits abgeschickt, aber kein Beleg empfangen, gilt ihre Wirkung als unbekannt. Sie muss zunächst überprüft werden, statt sie sofort erneut abzuschicken. Beim Wiederherstellen einer Sicherung werden zudem alte Aktionsfreigaben widerrufen und betroffene Aktionen als ungewiss markiert. Checkpoints beantworten, wo sicher weitergearbeitet werden kann; bereits eingetretene externe Wirkungen machen sie nicht rückgängig.

Eine andere Art von Checkpoint dient „Diesen Zug rückgängig machen“ (v0.1.63). Wenn ein Zug zum ersten Mal eine Datei schreibt oder einen Befehl ausführt, sichert Arslan den Arbeitsordner einmalig so, wie er war. Rückgängig macht stellt die Dateien wieder her und entfernt diesen Zug und jeden späteren aus der Unterhaltung, zusammen mit den Fakten, die sie vermittelt haben; Zusammenfassungen bleiben erhalten, und Nachrichten-IDs werden nie wiederverwendet. Der Ordner wird nur gesichert, wenn er höchstens 20.000 Dateien und 5 GB umfasst, genug freier Speicher vorhanden ist und er sich auf demselben Datenträger wie Arslans Daten befindet. Wiederherstellbare Ordner (Python-Umgebungen, node_modules, Build-Ausgaben, __pycache__) und Dateien in der Form von Geheimnissen werden ausgelassen und nie zurückgespielt; das Rückgängig-Feld nennt, was nicht gesichert wurde. Nach dem Zug geänderte Dateien bleiben erhalten und werden aufgelistet, und Rückgängig wird abgelehnt, solange ein Lauf den Ordner noch verändert.

Auch das Stoppen hat zwei Ebenen: Die Run Registry bricht wartende oder laufende asynchrone Arbeit ab. Der persistente Zustand verhindert, dass verspätete Ergebnisse weiter übernommen werden. Hat ein externes System eine Anfrage bereits akzeptiert, beweist der Abbruch des lokalen Wartens nicht, dass sie dort unausgeführt blieb. Die Aktionstabelle unterscheidet deshalb vorbereitet, gestartet, bestätigt, fehlgeschlagen, Wirkung unbekannt und abgebrochen. Die Wiederaufnahme klärt zunächst diese Zustände und entscheidet dann, welche Schritte erneut versucht werden können.

Quellcode: Aufgaben- und Abnahmeverträge; Persistente Zustände und Nebenläufigkeitsprüfung; Artefaktprüfung; Ausführung und ausdrückliche Fortsetzung; Trennung von Verbindung und Ausführung; Grenzen der Wiederherstellung aus Backups; Ordner-Checkpoints für Rückgängig; Rückgängigmachen eines Zuges.

Eine Runde, die das Fenster auf dem Laufenden hält

Seit 0.1.59 sendet der Server dem Fenster während einer laufenden Runde mindestens alle 15 Sekunden ein „working“-Ereignis, auch wenn das Modell minutenlang an einer einzigen langen Datei schreibt; „Interrupted“ bedeutet daher jetzt, dass die Verbindung selbst verloren gegangen ist. Seit 0.1.63 erreicht eine Nachricht, die gesendet wird, während Arslan noch antwortet, diese Antwort bei ihrem nächsten Schritt, statt auf deren Ende zu warten: Die noch nicht begonnenen Schritte werden übersprungen, die Antwort liest die Nachricht zuerst, und das Fenster sagt, dass sie hinzugefügt wurde. Eine Antwort, die bereits ihre Schlussantwort schreibt, hat keinen Schritt mehr übrig, die Nachricht läuft also direkt danach. Wartet eine Freigabekarte, beantwortet eine Nachricht sie mit Nein, mit der Nachricht als Anmerkung, und läuft als Nächstes. Die Antwortsprache folgt der jüngsten Nachricht des Nutzers: Pfade, URLs und Code werden bei ihrer Bestimmung ignoriert, und eine Nachricht ohne Wörter folgt der Sprache der Oberfläche. Eine Freigabe, die angefragt wird, während die Verbindung des Fensters geschlossen ist, lässt die Runde nicht mehr scheitern; die Karte wartet im Posteingang, in der Island oder im wieder verbundenen Fenster.

Quellcode: working-Ereignisse, Warteschlange und Karten nach einer Wiederverbindung; zu einer laufenden Antwort hinzugefügte Nachricht; Antwortsprache.

Projekte: ein Board, Etappen und Prüfpunkte, die Belege brauchen

Seit 0.1.56 hat ein Projekt einen Plan aus Etappen, jede mit einer klaren Bedingung und einigen Prüfpunkten. Die Wahl eines Typs (Spiel, App, Website, Recherche, Text, Video, Skill, Reise, Job oder Sonstiges) entwirft die Etappen aus einer Vorlage, ohne ein Modell aufzurufen. „Let Arslan refine“ passt sie mit einem einzigen Aufruf des vom Nutzer eingerichteten Modells an das Ziel an; gespeichert wird nichts, bevor der Nutzer das Projekt anlegt. Die Spalten des Boards – Idea, Shaping, Doing, Done – ergeben sich aus der aktuellen Etappe und werden nie per Ziehen verschoben; Done und Dropped setzt nur der Nutzer.

Arslan bewegt einen Plan nur anhand von Belegen, die es benennen kann, und nur für die aktuelle Etappe: Ein Prüfpunkt, der Dateien nennt, wird abgehakt, sobald diese im Projektordner erscheinen; nach einer Nachricht des Nutzers fragt ein Bewertungsmodell, ob sie besagt, dass etwas erledigt ist; ein Hintergrundjob, der aus der Übergabe des Projekts gestartet wurde, hakt seinen Prüfpunkt ab, wenn er als erledigt endet. Kleine Häkchen lassen sich rückgängig machen; der Abschluss einer Etappe ist ein Vorschlag auf der Karte, nie eine Benachrichtigung oder ein Eintrag im Posteingang. Erst nach zehn richtigen Einschätzungen in Folge fragt Arslan einmal, ob es Etappen selbst weiterschalten darf. Die gelernten Planregeln, das Arbeitstempo des Nutzers und der Hinweis „stockt“ bleiben lokal und erreichen ein Modell nur innerhalb einer Entwurfsanfrage, die der Nutzer selbst gestartet hat.

Quellcode: Etappen, Board und Vorschläge; Dateien, Aussagen des Nutzers, Ausführungen; Etappenvorlagen; Planregeln, Tempo und Stocken.

07 / Daten und GedächtnisNützlichen Kontext bewahren und Datengrenzen klar halten

Arslan speichert seine wesentlichen Zustände lokal in SQLite. Für Gespräche, Ausführungsverläufe, Aufgaben, persönliche Erinnerungen, Modellkonfiguration und Verbrauch gibt es eigene Datenmodelle. Ergebnisdateien werden auf den Datenträger geschrieben; den vollständigen Text sehr langer Werkzeugausgaben legt Arslan separat im Datenordner der App ab (sieben Tage lang aufbewahrt), und das Modell liest ihn abschnittsweise über den im Ergebnis angegebenen Pfad. Ein geschlossenes Fenster löscht damit keinen Aufgabenverlauf. Zugleich lassen sich getrennt verwalten, „was damals gesagt wurde“, „was tatsächlich getan wurde“ und „was künftig erinnert werden darf“.

Der Datenzugriff erfolgt asynchron über SQLAlchemy und aiosqlite. Verbindungen aktivieren WAL, Fremdschlüsselprüfung, eine Wartezeit von 5 Sekunden bei belegter Datenbank sowie synchronous=NORMAL. Diese Entscheidungen passen zu einer lokalen Einzelbenutzeranwendung: Sie verringern Bereitstellungsabhängigkeiten und verbessern gleichzeitiges Lesen und Schreiben. Eine kooperative Prozesssperre im Datenverzeichnis verhindert außerdem, dass Instanzen, die dasselbe Protokoll beachten, gleichzeitig dieselben Daten verwenden.

Datenobjekte sind nach Zuständigkeit gegliedert

Die Aufgabentabelle speichert den aktuellen Zustand, die Revisionstabelle die Aufgabenvereinbarung, die attempt-Tabelle Ausführungsversuche, die event-Tabelle geordnete Ereignisse und die action-Tabelle tatsächliche Aktionen samt Wirkungsstatus. Zusammen tragen sie Prüfung und Wiederaufnahme. Persönliche Erinnerungen trennen stabile Identität, Inhaltsrevisionen und Herkunft, um Bearbeitung, Nachverfolgung und Löschung zu ermöglichen. Nicht der gesamte Chat wird unmittelbar als dauerhaftes Gedächtnis übernommen.

Quellcode: SQLite-Verbindung; Modelle für Ausführungen, Material und Konfiguration; Aufgabenmodelle; Modelle für persönlichen Kontext und Gedächtnis.

Arbeitskontext: Eingaben begrenzen und Originalverlauf erhalten

Modelle können pro Aufruf nur begrenzt Inhalte aufnehmen. Arslan bildet den Arbeitskontext deshalb aus einer begrenzten fortgeschriebenen Zusammenfassung und jüngsten Nachrichten. Seit v0.1.63 richtet sich die Größe dieses Verlaufsfensters nach dem Modell der Runde: geschätzt 40 % seines Kontextfensters, nie unter 3.000 und nie über 24.000 Token (bei einem unbekannten Modell werden 32.000 angenommen, bei einem lokalen Modell 8.192); auch die Zusammenfassung selbst ist längenbegrenzt. Das ist das Budget für die Zusammenstellung des Verlaufs und bedeutet nicht, dass die gesamte Modellanfrage nur 3.000 Token umfasst: Systemanweisungen, Werkzeugschemas, Unterlagen und Ergebnisse belegen zusätzlichen Platz.

Wächst das Gespräch, bleiben die jüngsten vier Nutzerrunden im Wortlaut erhalten (solange sie in die Hälfte des Budgets passen), und die Werkzeugzusammenfassungen älterer Runden werden zuerst ausgeblendet, was nichts kostet; sobald der Verlauf drei Viertel seines Budgets überschreitet, werden ältere Nachrichten in die Zusammenfassung gefaltet, die die Abschnitte Ziel, Fortschritt, Entscheidungen, Berührte Dateien und Nächste Schritte beibehält. Was sich von Runde zu Runde ändert (Fakten, Zusammenfassung, Material, die Antwortsprache), steht in einem Referenzblock am Anfang der Anfrage der Runde, nicht im Systemprompt, und wird nie als Wortlaut des Nutzers gespeichert. Die Verdichtung bestimmt, welche Inhalte beim nächsten Mal zusammengestellt werden; sie löscht nicht die vollständige Sitzung aus der Datenbank. Auch bei einem Fehler der Verdichtung bleiben die Originalaufzeichnungen erhalten. Für lange Werkzeugausgaben gibt es einen separaten Speicherpfad: Das Modell erhält Auszüge vom Anfang und Ende sowie den Dateipfad und kann bei Bedarf abschnittsweise nachlesen. Die vollständige Ausgabe wird gemäß der Aufbewahrungsregel später bereinigt.

Diese Aufteilung priorisiert für das Modell die aktuell benötigten Informationen und erhält zugleich Originalbelege für spätere Prüfungen. Eine Zusammenfassung ist nur eine verdichtete Darstellung vorhandener Inhalte und ersetzt keinen tatsächlichen Beleg einer externen Aktion.

Persönliches Gedächtnis: Erst die Nutzungserlaubnis, dann die Relevanz

Ein Erinnerungseintrag enthält Typ, Geltungsbereich, Sensibilitätsstufe, Nutzungsrichtlinie, Status, Konfidenzinformationen und Version. Der Geltungsbereich kann global sein oder ein Projekt betreffen (daneben gibt es interne Bereiche wie Domäne und Experte); zudem gehört jeder Eintrag einem Eigentümer. Nutzungsrichtlinien wie local_only bestimmen zusätzlich, ob Inhalte in Anfragen an Cloud-Modelle gelangen dürfen. Der vertrauenswürdige Kontext jeder Runde lädt die Sitzungseinstellungen aus der Datenbank. Gewöhnlicher Nutzertext, Webseiten und Modellausgaben können diese Rechte nicht selbst umschreiben.

„Über dich“ und „Mac-Notizen“ werden in begrenztem Umfang grundsätzlich eingebunden; weitere Inhalte nach Relevanz ausgewählt. Seit v0.1.52 kann die standardmäßig aktivierte Einstellung „Informationen über mich merken und im Gespräch verwenden“ die Nutzung gewöhnlicher cloud_allowed-Einträge im konfigurierten Cloud-Modell erlauben. Sensible Inhalte benötigen zusätzliche Erlaubnis. local_only-Inhalte werden durch den allgemeinen Schalter nicht für die Cloud freigegeben.

ContextReceipt protokolliert verwendete Einträge und Revisionen, Verwendungsgrund und geschätzte Zählwerte, ohne den Erinnerungstext zu kopieren. Nutzer können damit die Grundlage einer Kontextauswahl nachvollziehen, ohne dass das System eine weitere Kopie sensibler Inhalte anlegt.

Eine Bearbeitung erzeugt eine neue Revision und aktualisiert den Verweis des Eintrags auf die aktuelle Fassung. Quellenaufzeichnungen erklären weiterhin, wie diese Fassung entstanden ist. Pausiert, abgelaufen, ersetzt oder gelöscht sind weitere Zustände, die den späteren Kontextzugang beeinflussen. Versionierung macht Änderungen nachvollziehbar; der Löschprozess entfernt jedoch zu löschende Texte. Es handelt sich deshalb nicht um ein Ereignisarchiv, aus dem historische Inhalte grundsätzlich nie entfernt werden können.

Quellcode: Verlauf und Zusammenfassung; Lange Werkzeugausgaben; Verlaufsgröße nach Modellfenster; Referenzblock pro Runde; Sitzungsberechtigungen; Umfangs- und Datenschutzfilter, Nutzungsbelege.

Materialsuche: Stichwörter und Vektoren kombinieren

Das Suchmodul für Wissensmaterial unterstützt Volltextsuche mit SQLite FTS5 und Vektorsuche über Kosinusähnlichkeit. Die erste findet Übereinstimmungen im Wortlaut, die zweite sucht mittels Embeddings semantisch verwandte Ausschnitte. Sind beide verfügbar, führt RRF ihre Ranglisten zusammen. RRF vergleicht Rangpositionen und vermischt nicht direkt Rohwerte unterschiedlicher Skalen. Ohne konfiguriertes Embedding oder bei fehlenden Vektoren bleibt die Volltextsuche nutzbar.

Gefundene Ausschnitte gelangen mit Quellenangaben in den Modellkontext; das Modell erstellt daraus unter Berücksichtigung der aktuellen Frage eine Antwort. Das ist hier mit RAG gemeint. Die Materialsuche läuft nur in Projekten mit gebundenen Materialsammlungen; bei einem Cloud-Modell muss zusätzlich die eigene Cloud-Gedächtnis-Erlaubnis des Gesprächs eingeschaltet sein (der standardmäßig aktivierte Schalter „Informationen über mich merken“ deckt Material nicht ab). Die Ergebnisse gelangen als Rückgabewert des Werkzeugs recall in den Kontext. Dazu müssen weder Gewichte des Basismodells verändert noch eine separate Vektordatenbank betrieben werden. Die Auswahl im persönlichen Gedächtnis v2 beruht überwiegend auf Berechtigungsfiltern, Volltextsuche und lokaler Relevanzlogik. Daraus lässt sich nicht ableiten, dass sämtliche Erinnerungen dieselbe Vektorpipeline durchlaufen.

Erfahrungslernen: Korrekturen in prüfbare Regeln überführen

Lesson speichert Nutzerkorrekturen, erfolgreiche Ausweichwege nach einem Fehler und Besonderheiten der Rechnerumgebung. Benötigt ein Befehl auf diesem Mac beispielsweise andere Parameter, kann daraus eine Erfahrung mit Quellenbezug für ähnliche Aufgaben entstehen. Höchstens 5 Einträge mit insgesamt ungefähr 800 Zeichen werden abgerufen. Sie stehen im dynamischen agent status und verändern nicht den stabilen Systempräfix. Abruf, Befolgung, Erfolg und Misserfolg besitzen jeweils eigene Zähler.

Die Judgment-Schicht kann eng begrenzte Einschätzungen dazu vorschlagen, ob ein Inhalt gespeichert werden sollte oder vorhandene Inhalte wiederholt beziehungsweise ihnen widerspricht. Sie erfasst dabei Wahrscheinlichkeiten und spätere Ergebnisse. Nutzerkorrekturen oder nicht von externen Inhalten beeinflusste Erfahrungen können unmittelbar aktiv werden, wenn die Einstellungen dies erlauben und die Bewertung einen Nutzen erkennt. Andere prüfpflichtige Inhalte werden als Vorschlag abgelegt. Kandidaten mit Zugangsdaten werden sofort verworfen; die Regel, dass abgeleitete sensible Informationen geprüft werden müssen, gilt für das persönliche Gedächtnis, nicht für Erfahrungen. Fehlende oder zeitlich abgebrochene Bewertungen haben Rückfallpfade.

Seit 0.1.55 gilt eine Korrektur nur dann als solche, wenn sie auf etwas antwortet, das Arslan zuvor im Gespräch getan hat: Eine erste Nachricht ist ein Auftrag, nie eine Korrektur. Widerspricht eine Korrektur dem Weg, der in derselben Runde gerade funktioniert hat, wird sie nicht sofort wirksam, sondern als Vorschlag abgelegt, der auf die Zustimmung des Nutzers wartet. Ein Fehler, den der Nutzer selbst beheben muss – etwa eine von macOS verweigerte Berechtigung –, wird nie als Grund gelernt, einen anderen Weg zu nehmen. Speichert Arslan während eines Gesprächs eine Erinnerung, teilt es das im Verlauf mit und bietet Rückgängig an.

Diese Mechanismen verändern das von der Anwendung gespeicherte und abgerufene Wissen, trainieren aber keine Modellgewichte. Auch der aktive Umfang von judgment unterscheidet sich je Einsatz: Die Bewertungspunkte für Gedächtnis, Erfahrungen und Projekte laufen nach der Antwort, und ein registrierter (Abschluss einer Runde) ist ausgeschaltet. Keine Bewertung entscheidet, ob ein Befehl ausgeführt wird: Die Schattenbewertung der Befehlskarten wurde in v0.1.63 entfernt, und nur der Freigabeablauf entscheidet.

Quellcode: Hybride Materialsuche; Erfahrungsextraktion und -abruf; Begrenzte Bewertungen und Betriebsmodi.

Löschungen müssen auch Zusammenfassungen und alte Sicherungen berücksichtigen

Beim Löschen einer Erinnerung erhöht das System die deletion epoch, entfernt die alten Revisionstexte und Quellen dieses Eintrags und leert die fortlaufenden Zusammenfassungen aller Gespräche sowie die in Ausführungsaufzeichnungen zwischengespeicherten Prompts, damit alte abgeleitete Inhalte die gelöschte Erinnerung nicht zurückbringen. Löschaufzeichnungen bewahren nur einen Inhaltsfingerabdruck zum Abgleich (ein HMAC mit lokalem Schlüssel) sowie Metadaten wie den Geltungsbereich, damit der gelöschte Text nicht erneut im Register landet. suppression-Einträge verhindern, dass dieselbe noch im Chatverlauf vorhandene Quelle die Erinnerung automatisch wieder erzeugt. Eine Erinnerung zu löschen und das ursprüngliche Gespräch zu löschen sind unterschiedliche Datenoperationen. „Diesen Zug rückgängig machen“ ist eine dritte, engere: Es löscht die Einträge, deren Quellen ausnahmslos rückgängig gemachte Runden sind (ein Eintrag, den auch etwas anderes stützt, verliert nur diese Quellen), hinterlässt keinen Texteintrag als Grabstein und behält Zusammenfassungen.

Ein eigenständiges Löschregister und ein Löschmanifest setzen Löschungen auch beim Start und bei Wiederherstellung fort. Vor dem Wiederherstellen einer alten Sicherung prüft das System die Speicheridentität. Noch vor der Aktivierung gleicht es die zwischengelagerten Daten mit den Löschinformationen ab. Das verringert das Risiko, dass alte Backups gelöschte Erinnerungen zurückbringen. Diese Zusage hängt vom Wiederherstellungsablauf und den verfügbaren Löschaufzeichnungen ab; bereits extern exportierte Kopien lassen sich damit nicht pauschal zurückholen.

Auch die übrigen Erinnerungen einer Sicherung erhalten nicht sofort alle bisherigen Nutzungsrechte zurück. Die Wiederherstellung isoliert sie zur Prüfung, verschärft Nutzungsrichtlinien, löscht zwischengespeicherten Kontext, deaktiviert alle geplanten Aufgaben, entzieht gesprächsbezogene Cloud- und Sensibilitätsfreigaben und archiviert laufende Projekte. Datenwiederherstellung und erneute Nutzungserlaubnis erfolgen getrennt, damit alte Sitzungsfreigaben in einer neuen Laufzeitumgebung nicht unbemerkt wirksam werden.

Erst die Migration, dann die Nutzung der Daten

Aktuell erfolgen Datenbankaktualisierungen über einen expliziten Migrations-Runner. Er prüft die Schemaversion, bereitet eine Sicherung vor, erstellt fehlende Tabellen und führt ausstehende Migrationen der Reihe nach aus. Danach folgen Schlüsselkompatibilität und Aktivierung von Gedächtnis v2. Unbekannte oder zu neue Schemas werden abgewiesen, damit ein älteres Programm neuere Daten nicht unkontrolliert verändert. In v0.1.63 reicht die ausdrückliche Registrierung bis 0070. Die frühere Alembic-Historie beschreibt nicht den aktuellen Laufzeitmechanismus. Seit v0.1.60 kamen 0067 (die Berechtigungstabellen), 0068 (ein Zustand pro MCP-Server und die Hinweise zu jedem Werkzeug), 0069 (Nachrichten-IDs werden nie wiederverwendet, damit das Rückgängigmachen einer Runde keine gelöschte ID erneut vergeben kann) und 0070 (ein gespeichertes „nur bei riskanten Befehlen fragen“ wird einmalig zu „vor jedem Befehl fragen“) hinzu.

Bei der Aktivierung von Gedächtnis v2 werden frühere Fakten- und Lerntabellen in Legacy-Tabellen umbenannt und durch Nur-Lese-Trigger geschützt. Kompatibilitätsansichten bilden alte Lesezugänge auf die neue Struktur ab; dabei entsteht auch der Volltextindex. Geheime Felder – Modell-API-Schlüssel, MCP-Umgebungsvariablen und OAuth-Tokens, SSH-Schlüssel und Ähnliches – werden auf Feldebene mit Fernet verschlüsselt (PBKDF2 plus ein Salt, das für jede Installation eigens erzeugt wird). Gewöhnliche Gesprächs- und Aufgabentabellen werden dadurch nicht zu einer vollständig verschlüsselten Datenbank. Persistenz, Schutz von Geheimnissen und Wiederherstellung haben jeweils konkrete Grenzen.

Quellcode: Erinnerungslöschung und Versionierung; dauerhafte Antworten und Antworten pro Aufgabe; Rückgängigmachen eines Zuges; Löschregister; Löschabgleich vor Wiederherstellung; Koordination der Backup-Wiederherstellung; Isolation wiederhergestellter Daten; Startreihenfolge des Speichers; Explizite Migrationen; Berechtigungstabellen; Aktivierung der Gedächtnisstruktur; Schutz der Schlüsselfelder.

08 / Werkzeuge, Skills und ErweiterungenFähigkeiten wiederverwenden und Ausführung begrenzen

Arslan organisiert „etwas ausführen können“ und „wissen, wie es geht“ getrennt. Werkzeuge übernehmen tatsächliche Aktionen, Skills speichern Vorgehensweisen und Referenzen, MCP bindet externe Fähigkeiten an, und Plugin-Manifeste fassen diese Ressourcen zusammen. Das Modell erhält die in der jeweiligen Runde verfügbaren Fähigkeiten. Ein Werkzeug im Quellcode-Register ist deshalb nicht automatisch aktiviert oder zur Ausführung freigegeben.

Wie die vier Begriffe zusammenspielen

Welche Prüfungen zwischen Deklaration und Ausführung liegen

Integrierte Werkzeuge werden von registrierten Ausführungsfunktionen verarbeitet; Aufrufe mit dem Präfix mcp_ gehen an den MCP-Proxy. Das Ergebnis kehrt in die einheitliche Schleife zurück. Daraufhin kann das Modell Parameter ergänzen, eine Alternative wählen oder die Aufgabe abschließen. Auch nach dem Lesen eines Skills müssen Datei-, Befehls- und App-Aktionen ihre jeweiligen Berechtigungsgrenzen passieren.

Seit 0.1.63 enthält eine Anfrage nicht mehr jedes Werkzeug. Sie enthält eine feste Menge alltäglicher Werkzeuge (Websuche und Seitenlesen, Dateien lesen, schreiben und bearbeiten, das Terminal, Planung, Hintergrundarbeit, Gedächtnis, read_skill, die Fähigkeitenliste und die Desktop-Werkzeuge von Hands) plus zwei Finder: find_tools ordnet die Werkzeuge, die diese Runde aufrufen darf, die ihr aber nicht gezeigt wurden, nach Relevanz, und use_tool ruft eines unter seinem echten Namen auf, sodass die Parameter gegen die eigenen Parameter dieses Werkzeugs geprüft werden und dieselbe Freigabe, Ablaufspur und dieselben Belege gelten wie bei einem direkten Aufruf. MCP-Werkzeuge, attach_file und die Browser-Werkzeuge werden auf diesem Weg erreicht. Ein bei Bedarf genutztes Werkzeug gehört ab der nächsten Runde zur Liste dieser Unterhaltung (höchstens 12 pro Unterhaltung, im Arbeitsspeicher gehalten, sodass das Modell nach einem Neustart erneut sucht). Text eines MCP-Servers, den find_tools zurückgibt, wird als externe Daten eingepackt, nie als Anweisung.

Verlangt das Modell mehrere Lesevorgänge hintereinander, laufen bis zu vier gleichzeitig: Websuche und Seitenlesen, read_skill, Dateilesen, Auflistungen und Ähnliches sowie MCP-Werkzeuge, deren Server sie als nur lesend kennzeichnet (eines pro Server in einer Gruppe). Jeder Aufruf durchläuft weiterhin jede Prüfung in der Reihenfolge der Antwort, und jedes Ergebnis bleibt dem Aufruf zugeordnet, der es angefordert hat; alles, was kein Lesevorgang ist, läuft allein an seiner Stelle.

Skills werden nach Bedarf gelesen: Der Index zeigt dem Modell die verfügbaren Methoden; read_skill lädt anschließend den Inhalt aus einem registrierten SkillPack oder einem erlaubten Referenzpfad. So kann die Methodensammlung wachsen, ohne den Kontext jeder Runde unbegrenzt zu vergrößern. Arslan liefert zwei eigene Skills mit, einen gestalteten HTML-Bericht und den Skill Creator. Seit 0.1.63 sind die Vorgaben aus der Expertenzeit, die voreingestellte MCP-Connector-Liste und das Werkzeug des Modells zum Vorschlagen von Connectoren entfallen (ein neuer MCP-Server wird über find_capability gefunden, siehe unten), und ein Skill, den Sie unter einem eingestellten Namen importiert haben, wird nicht mehr entfernt.

Seit 0.1.55 listet die Seite Capabilities auf, was Arslan kann, und zwar als Schalter: jeweils an, aus, einen Schritt entfernt oder hier nicht möglich, jeweils mit Begründung. Aus bedeutet, dass dem Modell die Fähigkeit gar nicht erst angeboten wird; read_skill verweigert einen ausgeschalteten Skill. Die Zeilen werden aus denselben Prüfungen gelesen, die festlegen, welche Werkzeuge eine Runde erhält. Eine Zeile kann daher nicht „an“ anzeigen, während ihre Werkzeuge fehlen. Ein Werkzeug whats_new beantwortet die Frage „Welche Version bist du, was hat sich geändert?“ anhand der mit der App ausgelieferten Release Notes, nie aus dem Gedächtnis des Modells.

Erweiterungsdienste bilden eine zusätzliche Vertrauensgrenze

Ein lokaler stdio-MCP-Dienst bedeutet in der Regel den Start eines eigenen Prozesses; HTTP-MCP kann einen entfernten Dienst ansprechen. Arslan muss Verbindung, Verfügbarkeit für den Hauptassistenten, Sichtbarkeit der Werkzeuge sowie Speicherung und Anzeige von Zugangsdaten getrennt verwalten. Die im Plugin-Manifest angegebene URL eines HTTP-MCP-Dienstes muss HTTPS verwenden. Secret-Felder deklarieren die Form der Parameter; echte Zugangsdaten werden nicht in das Manifest eingebettet. Konfigurierte Umgebungswerte werden verschlüsselt gespeichert und bei der Anzeige maskiert.

Seit 0.1.61 startet jeder MCP-Server, den Sie eingeschaltet haben, beim Öffnen von Arslan im Hintergrund, höchstens vier gleichzeitig, und ein Chat wartet nie auf einen. Jeder Server hat einen Zustand, den die Seite Capabilities und das Modell gemeinsam lesen, und dem Modell werden nur die Server angeboten, die gerade bereit sind; ein Aufruf eines anderen wird mit seinem Zustand und dem Grund beantwortet, wobei Schlüssel und Token maskiert sind. Ein erster Start erhält 120 Sekunden; ein fehlgeschlagener Server wird nach 30 Sekunden erneut versucht, danach seltener (höchstens alle 10 Minuten).

Seit 0.1.62 formt Arslan die Parameterbeschreibungen von MCP-Werkzeugen in eine Form um, die Anthropic, OpenAI-kompatible Anbieter und Gemini akzeptieren, bevor es sie sendet; integrierte Werkzeuge werden unverändert gesendet. Lehnt ein Anbieter eines trotzdem ab, wird dieses Werkzeug für den Rest der Antwort weggelassen, und die Antwort geht weiter (nennt die Ablehnung kein Werkzeug oder wird ein zweites abgelehnt, entfallen für diese Antwort alle MCP-Werkzeuge).

Seit 0.1.63 fragt ein MCP-Aufruf danach, was der Server über die Wirkung des Werkzeugs angibt: Ein Werkzeug, das der Server als nur lesend kennzeichnet, läuft ohne Karte; eines, das er als zerstörerisch kennzeichnet, fragt jedes Mal, nur dieses Mal; jedes andere fragt – dieses Mal oder für die Unterhaltung, nie „Immer“. Ein Aufruf, dessen Parameter zu lang sind, als dass eine Karte sie vollständig zeigen könnte, wird abgelehnt, nie gekürzt. Diese Kennzeichnungen sind die eigene Angabe des Servers, die Arslan nicht überprüft. Wo niemand gefragt werden kann (ein geplanter Lauf), laufen nur nur lesende Werkzeuge.

Diese Regeln verringern versehentliche Offenlegung und unbeabsichtigte Ausführung. Der tatsächliche MCP-Dienst kann jedoch weiterhin auf die Ressourcen zugreifen, die ihm zur Verfügung stehen. Herkunft der Werkzeuge, erforderliche Rechte, an entfernte Dienste gesendete Daten und Nebenwirkungen der Aktionen müssen deshalb bei Erweiterungen erklärt werden.

Wachsende Fähigkeiten: finden, fragen, installieren, prüfen, testen

Seit 0.1.57 gilt: Braucht ein Schritt etwas, das Arslan nicht kann, durchsucht find_capability gemeinsam die offizielle MCP Registry, GitHub und geprüfte Skill-Bibliotheken. propose_capability darf nur einen Kandidaten nennen, der in dieser Unterhaltung angezeigt wurde, und die Karte wird auf dem Server aus diesem Suchergebnis erstellt, nie aus den Worten des Modells: was hinzukäme, woher es stammt, seine Lizenz – gelesen aus der Lizenzdatei des Projekts selbst –, wie es ausgeführt würde, welche Ordner es verwenden darf und welchen Schlüssel es benötigt. Freigeben kann nur das Arslan-Fenster, das gefragt hat; ein Hintergrundauftrag oder eine Runde, in der niemand gefragt werden kann, legt den Fund stattdessen unter „Arslan found“ auf der Seite Capabilities ab.

Nach der Freigabe wird die Fähigkeit fest versioniert und ausgeschaltet installiert: über eine Lock-Datei mit Hashes, eine veröffentlichte Prüfsumme oder einen Commit, mit Arslans eigenem, fest versioniertem uv oder Node, ohne dass während der Installation Paketcode läuft (nur wheels, npm ohne Installationsskripte). Eine Prüfung sucht nach bekannten gefährlichen Mustern – versteckte Anweisungen in einem Skill, Code, der weiteren Code herunterlädt und ausführt, Schreibzugriffe dorthin, wo macOS Programme startet –, und ein schwerwiegender Befund entfernt die Installation wieder. Die Prüfung kann nichts als sicher beweisen; deshalb läuft der Server anschließend in seiner eigenen Sandbox (Kapitel 09). Er muss starten und mindestens ein Werkzeug auflisten, bevor er eingeschaltet wird, und die Werkzeugschleife liest seine Werkzeuge neu ein, sodass der fehlgeschlagene Schritt in derselben Antwort wiederholt werden kann. Von GitHub importierte Skills werden auf einen Commit festgelegt, mit einer Prüfsumme pro Datei, und ihr Text wird als externer Inhalt gelesen, der keine Berechtigungen erteilen kann.

Quelle: Fragen, Installieren, Prüfen, Testen, Einschalten; Fest versionierte Installation und Lizenz aus der Quelle; Prüfung auf bekannte Muster; MCP Registry, GitHub und Skill-Bibliotheken.

Dateien kommen als Dateien zurück: die Leseansicht der Arbeitsfläche

Seit 0.1.58 erscheint eine während einer Runde geschriebene Datei unter der Antwort als Karte, und Pfade in einer Antwort öffnen sich in Arslan oder im Dateibrowser. Die Leseansicht der Arbeitsfläche liest nur dort, wo auch Arslans eigene Lesewerkzeuge lesen dürfen: im Arbeitsbereich, in Desktop, Documents und Downloads, wenn das standardmäßige Lesen eingeschaltet ist, in den Ordnern aktiver Projekte und in Arslans eigenen Ausgaben. Symlinks werden zuerst aufgelöst, versteckte Dateien und Namen, die nach Zugangsdaten aussehen, werden nie aufgelistet oder gelesen, Dateibytes werden als Anhang mit nosniff gesendet, und HTML wird in einem iframe mit leerem sandbox angezeigt, sodass seine Skripte nicht ausgeführt werden können.

Seit 0.1.63 hängt attach_file eine Datei an die Antwort an, wenn Sie um eine Datei bitten (einen Screenshot, ein Diagramm, einen Export oder ein Dokument): eine Dateikarte im Fenster und die Datei selbst auf einem gekoppelten iPhone. Es braucht keine eigene Karte, weil es nur dort liest, wo auch die Leseansicht lesen darf, und es gelten dieselben Regeln: keine versteckten oder an Zugangsdaten erinnernden Namen, kein Link aus den lesbaren Ordnern hinaus. Es nimmt außerdem nie etwas aus Arslans eigenen Daten, aus Schlüsselbunden oder SSH-Schlüsseln, keine Datei über 20 MB und nicht mehr Dateien, als ein Lauf aufnehmen kann.

Quelle: attach_file; Zugelassene Leseorte und versteckte Namen; Dateibytes; HTML in der Sandbox.

Hands v2: das Bild eines Fensters, Stapel, den Vordergrund ausleihen, übernehmen

Hands liest ein Fenster weiterhin als seinen Bedienungshilfenbaum. Seit 0.1.60 kann jeder Blick zusätzlich ein JPEG genau dieses einen Fensters anhängen – nie des ganzen Bildschirms –, das im Arbeitsspeicher gehalten und nur an das Modell gesendet wird; es wird weder auf die Festplatte noch in den Trace oder in die Oberfläche geschrieben, und kann das Modell keine Bilder verarbeiten, liest stattdessen macOS Vision den Text lokal. Das lässt sich unter Einstellungen › Hands ausschalten oder für Apps, die der Nutzer auflistet, auf Text beschränken. Mehrere Schritte in einer App laufen als ein Stapel von bis zu acht Schritten, Menüpunkte werden direkt gewählt, auch wenn die App nicht im Vordergrund ist, und Apps werden im Hintergrund geöffnet. Bis 0.1.62 durfte eine Chatantwort höchstens fünf Aktionen ausführen, alle in einer App; ab 0.1.63 hat sie keine eigene Hands-Grenze mehr und handelt innerhalb der Grenzen des Laufs, wie ein Hintergrundjob. Ein geplanter Lauf kann auf dem Mac gar nicht handeln: Niemand ist da, um es freizugeben.

Manches funktioniert nur, wenn die App im Vordergrund ist, etwa ein Pop-up-Menü. Hands wartet dann auf eine Tipppause von einer Sekunde, leiht sich den Vordergrund für etwa eine Sekunde aus, während die Ränder aller Bildschirme blau leuchten, hält in dieser Zeit gedrückte Tasten zurück und spielt sie erneut ein, sobald die App des Nutzers wieder vorn ist. Liegt das Fenster der App auf einem anderen Schreibtisch (Space), wechselt Hands unter denselben Regeln dorthin und kehrt zurück, wenn die Arbeit endet, nach 15 Sekunden ohne Aktion oder bei der ersten Eingabe des Nutzers. Für längere Arbeit kann ein Hintergrundjob darum bitten, den Bildschirm für bis zu 30 Minuten zu übernehmen; jede Tastatur- oder Mauseingabe pausiert die Übernahme, bis der Nutzer fortfährt. „While I'm away“ ist standardmäßig ausgeschaltet; ist es eingeschaltet, darf eine Übernahme nach drei Minuten ohne Eingabe auch ohne Karte beginnen. Das Ausleihen lässt sich ausschalten; Hands lehnt dann stattdessen ab.

Quelle: Ein Fenster, nichts wird gespeichert; Vordergrund ausleihen; Anderer Schreibtisch; Übernahme und Eingabepause; Aktionen im Chat, Stapel und Menüs; Einstellungen › Hands.

Suche und Lesen im Web

Seit 0.1.63 nutzt web_search zuerst die Suche des Modells, auf dem diese Runde läuft: Anthropics eigene Websuche für eine Claude-Unterhaltung über Anthropics eigene API, die von DeepSeek für ein DeepSeek-Modell. Eine Unterhaltung mit einem lokalen Modell sendet ihre Suchanfragen nie an die eigene Suche eines Anbieters. Tavily oder ein selbst gehostetes SearXNG, in den Einstellungen gewählt, ist entweder die einzige Suche oder eine Ersatzsuche nach der des Modells; ohne bewusste Wahl steht ein Best-Effort-Scraping von DuckDuckGo an letzter Stelle. Lehnt ein Suchdienst Arslan ab, sagt das Ergebnis, dass die Suche blockiert wurde und nichts gesucht wurde, nie „keine Ergebnisse“.

Seitenlesen und der Browser behalten den Schutz für ausgehende Verbindungen: lokale Namen, echte private Adressen und Hosts mit Steuerzeichen werden abgelehnt. Seit 0.1.61 wird auf einem Mac, dessen Proxy oder VPN DNS mit Fake-Adressen (198.18.0.0/15) beantwortet, ein Name, der über https auf Port 443 angefragt wird und dessen Adressen alle in diesem Block liegen, durchgelassen, während schlichtes http oder ein anderer Port zu einem solchen Namen abgelehnt wird. Bei einem solchen Namen entscheidet der Proxy, wohin die Anfrage wirklich geht; was weiterhin gilt, ist TLS, gegen den echten Namen geprüft.

Quelle: Suchreihenfolge und blockierte Suchen; Suchen der Anbieter; Schutz für ausgehende Verbindungen und Fake-IP-Ausnahme.

Warum parallele Recherche weiterhin möglich ist

Die einheitliche Agent-Schleife enthält weiterhin eingeschränkte temporäre Worker mit rein lesendem Zugriff. In v0.1.63 sind höchstens 4 Aufträge pro Gruppe und 2 gleichzeitig laufende Worker erlaubt. Ihre Werkzeuge sind auf Suche und Webseitenextraktion beschränkt. Sie schreiben weder Dateien noch persönliche Erinnerungen und können nicht rekursiv weitere Worker erzeugen. Der Hauptassistent prüft und integriert ihre Ergebnisse.

Diese Delegation eignet sich für voneinander unabhängige Informationsabfragen. Ihr Lebenszyklus unterscheidet sich von den früheren dauerhaften Expertenfiguren: Nutzer müssen vorher kein Expertenteam auswählen oder verwalten, und nicht jede Nachricht wird zwingend an einen anderen „Experten“ weitergeleitet. Ob Parallelität sinnvoll ist, hängt weiterhin von der Zerlegbarkeit der Aufgabe und den zusätzlichen Aufrufkosten ab.

Hintergrundaufgaben, Zeitplanung und Heartbeat

Hintergrund-Jobs trennen längere Ausführungen vom aktuellen Chat und verwenden dieselbe Modell-, Werkzeug- und Abnahmelogik. Geplante Aufgaben speichern dauerhaft, wann eine Ausführung beginnen soll. Heartbeat ist eine Form regelmäßiger Checklistenprüfung, standardmäßig ausgeschaltet und für Prüfungen sowie Vorschläge zuständig. Ein zeitgesteuerter Start macht aus einem Vorschlag keinen genehmigten Schreibzugriff oder Befehl. Seit 0.1.63 ist jeder geplante Lauf eine gewöhnliche Arslan-Runde, in der niemand gefragt werden kann: In dieser Version führt er überhaupt keinen Terminalbefehl aus, was auch immer zuvor erlaubt war, schreibt nur in Arslans eigenem Ordner, kann nicht auf dem Mac handeln und führt nur MCP-Werkzeuge aus, die ihr Server als nur lesend kennzeichnet; ein Schritt, der mehr braucht, wird abgelehnt und im Posteingang aufgeführt.

Chat-Antworten und Hintergrundaufgaben halten an einem Dollar-Limit pro Aufgabe an (standardmäßig eingeschaltet, 2 $; sie beginnen bei etwa zwei Dritteln davon mit dem Abschluss; nur Modelle mit bekanntem Preis zählen), das sich in den Einstellungen ändern lässt. Eine Chat-Antwort wird für lange Arbeit nicht mehr in den Hintergrund geschoben: Hintergrundarbeit ist dieselbe Arbeit an anderer Stelle, wenn Sie oder das Modell sie wählen.

Die aktuelle Zeitplanung läuft im lokalen Dienst. Sie überspringt Überschneidungen, pausiert bei Fehlern und bereinigt Zustände nach Neustarts. Verpasste Zyklen werden nicht einzeln nachgeholt. Ist die vorige Ausführung einer Aufgabe noch nicht beendet, wird keine weitere darübergelegt. Dieses Verhalten passt zu einer persönlichen Desktopanwendung; ihre Betriebsbedingungen unterscheiden sich damit von denen eines dauerhaft erreichbaren Servers.

Implementierung: Werkzeugregister und read_skill; Fähigkeiten als Schalter; Vertrag des Plugin-Manifests; MCP-Verbindung und Konfiguration; find_tools und use_tool; gleichzeitige Lesevorgänge; MCP-Start und Zustände; MCP-Aufrufe und Freigabe nach den Kennzeichnungen des Servers; Umformung der MCP-Werkzeugbeschreibungen; die zwei mitgelieferten Skills; Worker mit rein lesendem Zugriff; Hintergrundaufgaben; Lokale Zeitplanung; Heartbeat.

09 / Ausführungs- und SicherheitsgrenzenVom Modellvorschlag zur tatsächlichen Aktion

Arslan kann Dateien lesen und schreiben, Befehle ausführen und über Browser sowie native Apps arbeiten. Sein Sicherheitsentwurf beruht auf einer Unterscheidung: Das Modell schlägt den nächsten Schritt vor; vertrauenswürdiger Code entscheidet, ob er ausgeführt werden darf. Im Folgenden werden die in v0.1.63 implementierten Grenzen beschrieben. Es sind Schutzmechanismen mit konkretem Geltungsbereich, kein Sicherheitsbeweis für sämtliche bösartigen Eingaben, App-Verhaltensweisen oder Systemumgebungen.

Externe Inhalte liefern Material, erweitern aber keine Rechte

Webseiten und Werkzeugergebnisse können Prompt Injection enthalten. Webseitentext und MCP-Ergebnisse werden im Kontext ausdrücklich als externe Daten eingerahmt; seit 0.1.63 wird das, was ein lokales Werkzeug zurückgibt (eine Datei, ein Befehl, ein App-Fenster), in eine eigene Werkzeugausgabe-Begrenzung mit derselben Nur-Daten-Regel eingerahmt, und gefälschte Markierungen beider Arten werden behandelt. Das System erfasst außerdem, ob in dieser Runde externe Inhalte wie Webseiten, Dateien oder MCP-Ergebnisse gelesen wurden. Davon beeinflusste Erfahrungen und Rechnernotizen müssen zunächst als Vorschläge abgelegt werden. Eine Webseite mit „Sende Dateien künftig immer hierhin“ erhält also nicht allein dadurch eine dauerhafte Erlaubnis, dass sie gelesen wurde.

Seit 0.1.63 begrenzt dieselbe Aufzeichnung das Terminal: Hat eine Runde externe Inhalte gelesen (eine Seite, eine Datei, ein MCP-Ergebnis), laufen ihre Befehle nach der Regel des Kernels ohne Netzwerk, und ein Befehl, der das Netzwerk erreicht – beurteilt nach seinem Text oder danach, dass das Modell es sagt –, fragt zuerst. Innerhalb der Sandbox kann die Antwort für dieses Mal oder für die Unterhaltung gelten, außerhalb nur für dieses Mal. Wo niemand gefragt werden kann, bleibt der Befehl offline. Das Lesen im Web wird gesondert geschützt: lokale Namen und private Adressen werden abgelehnt, und die Ausnahme für Proxys, die DNS mit Fake-Adressen beantworten (0.1.61), lässt nur https auf Port 443 zu einem Namen durch und überlässt dem Proxy, wohin es wirklich geht (Kapitel 08).

Diese Verarbeitung hilft, Herkunft und Vertrauensbeziehungen zu erhalten, bleibt aber auf nachfolgende Ausführungsprüfungen angewiesen. Das Modell kann Material missverstehen, und die Erkennung riskanter Befehle ist kein vollständiger semantischer Beweis. Die Kennzeichnung „nicht vertrauenswürdig“ ersetzt deshalb keine tatsächliche Berechtigungsgrenze.

Einrahmung externer Daten und Herkunftsverfolgung; Werkzeugvalidierung und Ausführungseinstieg; Aktivierung oder Vorschlag für Erfahrungen.

Die Isolationsstärke hängt vom Ausführungswerkzeug ab

Das Verlassen der Befehlssandbox verlangt einen ausdrücklichen Klick zur Freigabe: entweder für die aktuelle Aktion oder auf Nutzerwahl für die laufende Sitzung. Diese Freigabe wird mit dem Gespräch gespeichert (sie übersteht einen Neustart), gilt auch für seine Hintergrundaufgaben und lässt sich in den Einstellungen zurücknehmen. Die Quellcode-Entwicklungsumgebung hat zusätzlich eine ausdrücklich zu aktivierende Ausnahmeeinstellung für Python ohne Sandbox. Die Desktop-App schließt diesen Ausweg. Keiner der beiden Mechanismen erlaubt dem Modell, Schutzvorkehrungen eigenständig auszuschalten.

Seit 0.1.62 folgen write_file und edit_file nie einem Link aus dem Arbeitsordner hinaus: Ein Schreibzugriff über einen Link, der nach außen zeigt, wird abgelehnt, eine Datei mit einem zweiten Namen anderswo (ein Hardlink) wird im Arbeitsordner ersetzt, und der andere Name behält seinen alten Inhalt, neue Dateien sind nie ausführbar, und eine bestehende Datei behält ihre Berechtigungen. Die Datei wird in eine neue Datei daneben geschrieben und eingetauscht, sodass ein fehlgeschlagener Schreibvorgang die alte unberührt lässt. Seit 0.1.63 sichert die erste Änderung, die eine Runde am Arbeitsordner vornimmt, einen Checkpoint, und „Diesen Zug rückgängig machen“ spielt die Dateien zurück und nimmt die Runde aus der Unterhaltung. Das ist ein Auffangnetz, keine Grenze: Es sichert nur einen Ordner mit höchstens 20.000 Dateien und 5 GB (ohne Python-Umgebungen, node_modules, Build-Ausgaben und Caches, die es auslässt und nie zurückspielt), kopiert nie Dateien in der Form von Geheimnissen, deckt nur den Arbeitsordner ab, macht nichts rückgängig, was den Mac verlassen hat, und sagt „Not saved“, wenn es nicht sichern konnte. Checkpoints werden sieben Tage aufbewahrt.

Beschränkte Rechenumgebung und Entwicklungsausnahme; Regeln für Arbeitsbereich und geschützte Verzeichnisse; Sandbox installierter Server; Fallback normaler Befehle und Ablehnung im Offline-Modus; Befehlsrichtlinie; Schreiben ohne Links zu folgen; Checkpoints; Diesen Zug rückgängig machen.

Freigaben gelten für konkrete Aktionen; Hintergrundarbeit erbt nicht alle Erleichterungen

Eine Freigabekarte ist über call_id und Aktionsart zugeordnet. Eine Antwort der falschen Art kann keine andere Karte freigeben. Sehen Mac-Fenster und Telefon dieselbe Karte, zählt die erste gültige Antwort; an die übrigen Ansichten wird ihr Abschluss gesendet. Ohne Antwort bleibt sie 30 Minuten offen, und dass die Zeit abläuft, ist kein Nein (seit 0.1.61; frühere Versionen: Ablauf nach 300 Sekunden). Seit 0.1.61 sieht eine Karte im Fenster, im Posteingang, in der Island und auf dem iPhone gleich aus: Einmal (oder Für diese Aufgabe, je nachdem, was die Karte zuerst anbietet), In diesem Gespräch, Immer und Nein mit einer Anmerkung, die an Arslan geht; eine Nachricht, die im Chat getippt wird, während eine Karte wartet, beantwortet sie mit Nein, mit dieser Nachricht als Anmerkung, und ein Klick beantwortet eine Karte. Manche Arten bieten weniger Auswahlmöglichkeiten: Ein Befehl, der auf eine Regel trifft, Geld, eine Übernahme und ein riskanter Schritt in einer App werden nur für dieses Mal beantwortet, und das Verlassen der Sandbox, eine Website, ein Shortcut und ein MCP-Werkzeug bieten nie „Immer“ an. Die Karten einer Hintergrundaufgabe bieten dieselben Auswahlmöglichkeiten wie die des Fensters; seit 0.1.63 (S4a) nutzt eine aus einem Gespräch gestartete Hintergrundaufgabe die Freigaben dieses Gesprächs, auch das Verlassen der Sandbox. Ein Lauf, in dem niemand gefragt werden kann (ein geplanter Lauf), nimmt keinen dieser Schritte: Keine frühere Antwort zählt dort, der Schritt wird sofort abgelehnt, und was er nicht tun konnte, wird im Posteingang aufgeführt. In dieser Version führt ein geplanter Lauf überhaupt keinen Terminalbefehl aus. Schlägt das Modell eine MCP-Verbindung, die Registrierung eines entfernten Rechners oder einen anderen Ausführungszugang vor, bleiben Vorschlag und tatsächliche Aktivierung der Verbindung getrennt.

Bei externen Nebenwirkungen ist das Absenden einer Anfrage ebenfalls nicht gleichbedeutend mit der abgeschlossenen Aktion. Bei Wiederaufnahme werden ausstehende Aktionen mit ungeklärtem Ergebnis als ungewiss markiert. Ein Prozessneustart allein darf keine automatische Wiederholung auslösen. Das Ziel sind klare Regeln für Wiederholung und Wiederaufnahme, keine Zusage, beliebige externe Systeme könnten Aktionen rückgängig machen.

Seit 0.1.55 steht jede wartende Karte – ob aus einem Fenster, einer Hintergrundaufgabe oder vom iPhone – zusätzlich in einer gemeinsamen Warteschlange und im Posteingang und lässt sich dort über ihre call_id beantworten. Die Antwort wird aus der Art der Karte selbst gebildet; sie kann also nur genau diese Karte bestätigen oder abbrechen, und die weiteren Auswahlmöglichkeiten (In diesem Gespräch, Immer) lassen sich nur auf einer Karte wählen, die sie anbietet: Das iPhone und die Island geben nur die erste Auswahlmöglichkeit der Karte, nie „Immer“, und der Posteingang kann jede Auswahlmöglichkeit geben, die die Karte selbst angeboten hat. Die Island kann Karten für Ordner, Apps, Bildschirm, MCP-Werkzeuge, Zeitplan, Websites und Shortcuts sowie für einen Befehl oder Schreibzugriff im Arbeitsbereich beantworten, der nicht zu den riskanten Arten gehört. Sie kann kein Geld, kein Senden, kein Löschen, keinen riskanten Schritt in einer App, keine Übernahme, kein Verlassen der Sandbox, keinen Befehl, der auf eine Terminal-Ask-Regel trifft oder sich nicht lesen lässt, keinen Befehl, der zusätzlich das Netzwerk verlangt, nichts auf einem entfernten Rechner, keine Systemänderungen, keine Einstellungen anderer Agenten, kein Installieren einer Fähigkeit, kein AppleScript, keinen Befehl, der ohne Sandbox um sich laufen würde, und keine Kartenart freigeben, die die Prüfung nicht kennt. Solche Karten zeigen „Open in Arslan“, und der Server lehnt eine Freigabe aus der Island für sie ab – nicht nur die Island-Oberfläche. Eine Karte, die ein freigegebenes einfaches AppleScript oder einen Shortcut ohne Sandbox-Hülle ausführen würde, und eine, die eine Fähigkeit installiert, werden nur im Mac-Fenster freigegeben; das Ja des iPhones zu einer solchen Karte wird verschluckt. Im Fenster erlaubt ⌘⏎ und Esc lehnt ab; ein einfaches ⏎ beantwortet nie eine Karte.

Antworten aus Posteingang und Island; Kartenzuordnung, Ablauf und Antworten mehrerer Geräte; Ungewisse Nebenwirkungen bei Wiederherstellung; Verbindungsvorschläge und Freigabeeinstieg.

Hands bündelt Systemrechte in einem kleineren Prozess

Accessibility wird Arslan Hands.app erteilt, nicht der Haupt-App. Signierte Releases nehmen Anfragen über einen geschützten Unix-Socket, ein bei jedem Start erzeugtes Token und eine Prüfung der Peer-Signatur entgegen. Der Helper setzt seine Regeln selbst durch; das darunterliegende agent-desktop besitzt die Berechtigung nicht separat. Seit 0.1.61 sind das Ansehen einer App und das Handeln in ihr eine Karte pro App, die „für diese Aufgabe“ zuerst anbietet. Seit 0.1.60 darf auch eine Chatantwort handeln: bis 0.1.62 mit bis zu fünf Schritten in einer App, ab 0.1.63 innerhalb der Grenzen des Laufs selbst, wie ein Hintergrundjob, in mehr als einer App, und Stop hält sie an (ein geplanter Lauf kann nicht handeln: Niemand ist da, um es freizugeben); ein aus einer Sitzung gestarteter Job übernimmt das Ja dieser Sitzung. Handeln im Browser, das Ausführen von Shortcuts und AppleScript werden weiterhin nur Hintergrundarbeit angeboten. Eine App wird nach ihrer Identität beurteilt; sie mit .app oder einem vollständigen Pfad oder in anderer Groß- und Kleinschreibung zu nennen, umgeht also weder die Sperrliste noch eine fehlende Freigabe. Sensible Schaltflächen wie Löschen, Senden, Bezahlen, Kaufen, Überweisen und Absenden verlangen anhand ihres tatsächlichen Labels jedes Mal eine Rückfrage. Passwortfelder werden nicht befüllt; Passwortmanager, Systemsicherheitsoberflächen und ähnliche Apps stehen auf der Sperrliste.

Der Stoppzugang setzt eine Stoppsperre, die nachfolgende Aktionen prüfen müssen. Aktivitätsaufzeichnungen halten Aktionsspuren fest; bei eingegebenem Text wird nur die Länge protokolliert. Auch die Grenzen sind dokumentiert: Ein Fenster in einem anderen Space erreicht Hands nur, indem es ihn nach den Regeln für das Ausleihen besucht; Klicks auf eine Bildschirmposition und Ziehen werden nicht angeboten; große Fenster können 10–20 Sekunden zum Auslesen benötigen. Durch Stop abgeschnittene Aufrufe können ohne zugehörige Trace-Zeile bleiben. Das Auditprotokoll ist daher keine Zusage vollständiger forensischer Nachweise für jeden Unterbrechungsfall.

Seit 0.1.56 führt Hands jede Anfrage höchstens einmal aus: Antworten auf eine Anfrage-ID werden zehn Minuten lang aufbewahrt, eine wiederholte ID wird von dort beantwortet, und hat das Backend eine Antwort verloren, ruft es diese ab, statt die Aktion erneut zu senden. Das Anhängen an ein Feld, dessen Text sich nicht lesen lässt, wird abgelehnt, statt den Inhalt zu ersetzen; Return wird nur gedrückt, wenn dieses Feld den Fokus hat; und eine Aktion, die gesendet, aber nicht zurückgelesen wurde, wird als „sent, not confirmed“ gemeldet, nicht als erledigt. Hands führt agent-desktop aus, gebaut aus Arslans Fork auf einem fest versionierten Commit; die Cua-Driver-Engine wurde in 0.1.63 aus Hands herausgelöst, sodass der Helper sie nicht mehr sucht oder startet (ihr ungenutztes Modul liegt noch im Quellcode des Helpers). Seit 0.1.60 kann eine einzige Karte bis zu acht Apps für eine Arbeit abdecken, ein aus einer Unterhaltung gestarteter Hintergrundjob übernimmt das Ja dieser Unterhaltung, und Apps lassen sich unter Einstellungen › Hands dauerhaft erlauben. Ein Klick, eine Auswahl oder ein letzter Menüpunkt mit der Beschriftung Löschen, Senden, Bezahlen, Kaufen, Absenden, Überweisen, Signieren, Posten, Veröffentlichen oder Bestätigen (in mehreren Sprachen), die entsprechenden Tastenkürzel, Return in Apps, die mit Return senden, eine Übernahme und jedes AppleScript verlangen weiterhin jedes Mal eine Rückfrage.

Socket-, Token-, Peer- und Stoppprüfungen; Gesperrte Apps und Einstufungen; Wörter und Tasten, die immer nachfragen; Praxistests und Grenzen von Hands; API- und WebSocket-Authentifizierung.

10 / iPhone und Mac BridgeAufträge und Ergebnisse auf dem Telefon, Ausführung auf dem Mac

Über die mobile Bridge kann ein gekoppeltes iPhone Mac-Aufgaben ansehen, Arbeiten anstoßen, Freigaben beantworten und Ergebnisse lesen. Ausgeführt wird weiterhin durch Arslan auf dem Mac. Das Telefon ist weder ein zusätzlicher Cloud-Agent-Dienst noch legt es die HTTP-Schnittstelle des Mac offen oder ruft sie direkt auf. Dieses Kapitel bezieht sich auf das öffentliche Protokoll und den Quellcode der Mac-Version v0.1.63. Die Mac Bridge wurde bereits in früheren Releases ausgeliefert. Ihre öffentlichen Release Notes bezeichnen die iPhone-App weiterhin als demnächst im Store verfügbar. Daraus wird hier weder eine abgeschlossene App-Store-Veröffentlichung noch eine vollständige Abnahme des Produktionsablaufs abgeleitet. Änderungen seit 0.1.60 sind dort, wo sie vorkommen, mit ihrer Version gekennzeichnet; die Notes zu 0.1.61 sagen, dass die Mac-Seite mit Arslan für iPhone 1.0 zusammenarbeitet, das weiterhin als demnächst im App Store verfügbar beschrieben wird.

CloudKit dient als Postfach; Geräteidentität prüft weiterhin das Protokoll

v1 verwendet die private CloudKit-Datenbank derselben Apple ID. Der Mac muss eingeschaltet, online und ausführungsbereit sein. Andernfalls warten Nachrichten auf Verarbeitung; das Telefon kann einen ausgeschalteten Mac nicht weiterarbeiten lassen. Bonjour im lokalen Netzwerk ist eine künftige Entwicklungsrichtung und kein alternativer Direktkanal dieser Version. Der Mac-Helper ist eine eigenständige ArslanBridge.app, die zusammen mit der Anwendung läuft. Sie erhält das lokale API-Token über stdin und verbindet sich damit zum Backend. Das Telefon besitzt dieses Token nicht und erhält auch keinen Modell-API-Schlüssel.

Zu den in der Cloud sichtbaren Indexfeldern eines Umschlags gehören Sender- und Empfängergerät, Sequenznummer, grobes kind, Benachrichtigungsmarkierung und Zeit. Der eigentliche Nachrichtentyp, Text und Dateiinhalt liegen im auf Anwendungsebene verschlüsselten Teil. „Ende-zu-Ende-Verschlüsselung“ beschreibt damit den Nachrichtenschutz zwischen gekoppelten Geräten. Sie bedeutet weder Metadatenfreiheit noch, dass Modellaufrufe des Backends den vom Nutzer konfigurierten KI-Dienst umgehen.

Transport, Umschläge und Mac-Anbindung; CloudKit-Speicherimplementierung; Laufzeiteinstieg der Bridge.

Der QR-Code beginnt die Kopplung lediglich

Der QR-Code enthält eine einmalige pairing_id, die öffentlichen Signatur- und Austauschschlüssel des Mac, einen 32 Byte langen Kopplungsschlüssel, eine feste Containerkennung und eine Frist. Er gilt höchstens 600 Sekunden. Das Telefon lehnt abgelaufene Angaben, falsche Container und nicht regelkonforme Inhalte ab und bindet sich an die öffentlichen Mac-Schlüssel aus dem QR-Code. Anschließend erzeugt es eigene Identitäts- und Austauschschlüssel und sendet eine verschlüsselte Kopplungsanfrage. Nach deren Prüfung muss der Mac sie weiterhin dem Nutzer anzeigen. Erst ein Klick auf dem Mac entscheidet über Annahme oder Ablehnung.

Eine Wiederholung derselben Anfrage muss dieselbe Entscheidung liefern und darf keine zweite Autorisierung erzeugen. Nach Annahme kommunizieren die Geräte anhand ihrer Identitäten; der Kopplungscode ist verbraucht. Der Mac kann das Telefon widerrufen. Koppelt sich dasselbe iPhone erneut, nennt es seine früheren IDs, und der Mac entfernt diese Einträge, statt zwei nebeneinander zu führen. Wird ein Telefon entfernt, löscht der Mac auch die Nachrichten, die er in iCloud für es hinterlegt hatte; beim Start räumt der Mac außerdem auf, was noch für nicht mehr gekoppelte Telefone wartet. Unter Einstellungen › Verbindungen › iPhone erscheint jedes Telefon als Connecting…, bis der Mac eine authentifizierte Nachricht von ihm gelesen hat, danach als Connected mit dem Zeitpunkt, zu dem es zuletzt gesehen wurde. Private Geräteschlüssel liegen jeweils in der Keychain. Vertrauen entsteht aus einmaligem Kopplungsmaterial und Nutzerbestätigung, nicht allein daraus, dass beide Geräte dasselbe iCloud-Konto verwenden. Seit 0.1.60 gilt: Hebt das iPhone die Kopplung selbst auf, vergisst der Mac dieses Telefon wie nach Einstellungen › Entfernen, ignoriert alles Weitere von ihm und aktualisiert die Liste.

Nachrichten prüfen Inhalt, Herkunft und Kontext gemeinsam

Jede neue Nachricht handelt mit einem temporären X25519-Schlüssel ein gemeinsames Geheimnis aus. HKDF-SHA256 leitet daraus einen 32 Byte langen Schlüssel ab; ChaCha20-Poly1305 verschlüsselt und authentifiziert, anschließend wird mit Ed25519 signiert. Der Header besteht aus längencodierten UTF-8-Feldern, damit sprachabhängige Unterschiede in der JSON-Sortierung die Prüfung nicht beeinflussen. Headerfelder sind sowohl durch Signatur als auch AEAD-Authentifizierung gebunden. Dieses Anwendungsprotokoll nutzt CryptoKit-Primitive. Es implementiert keine Signal Double Ratchet; allein aus temporären Schlüsseln folgt auch keine Zusage von Forward Secrecy in allen Szenarien.

Die Empfangsreihenfolge ist festgelegt: Struktur und Empfänger prüfen, Signatur verifizieren, dann entschlüsseln. Danach wird die Übereinstimmung von Klartext und Headerfeldern geprüft; vorhandene Anhänge folgen anschließend. Scheitert ein Schritt, darf keine teilweise fachliche Wirkung zurückbleiben. Dateien sind auf 20 MiB begrenzt. Prüfsumme des Chiffretexts, Authentifizierungstag, Klartextgröße und Klartextprüfsumme müssen stimmen, bevor Zwischenspeicherung oder Vorschau erlaubt sind.

Kopplung, Kryptoverfahren und Prüfreihenfolge; Mac-Codierung und Kryptoprotokoll; Einmalige Kopplung und Nutzerentscheidung.

Erfolgreiche Zustellung, abgeschlossene Aktion und endgültiger UI-Status sind getrennt

Mac-Statussnapshots führen nur noch laufende Aufgaben auf. Der normale Heartbeat-Abstand beträgt 60 Sekunden; nach 90 Sekunden ohne Aktualisierung bewertet das Telefon den Mac als offline. Fortschrittsmeldungen werden gedrosselt und zusammengefasst, Endzustände sollen zeitnah gesendet werden. Der Client muss deshalb Duplikate und vertauschte Reihenfolgen behandeln und zugleich Aufgabenlisten, Freigabekarten und Verlauf zu einem konsistenten Zustand führen. „Der zuletzt empfangene Text überschreibt den vorherigen“ genügt dafür nicht.

Sequenznummern, Verarbeitungsaufzeichnungen, ACK und Bereinigung; Fachliche Deduplizierung und Ergebniszuordnung; Snapshots und Heartbeats.

Mobile Freigaben verwenden die bestehende Mac-Autorisierung und Ausführung

Das Telefon zeigt die konkrete action, target und risk an. Eine Zustimmung erfordert lokale biometrische Authentifizierung, eine Ablehnung nicht. Nach dem Senden der Antwort muss es weiterhin auf approval.result vom Mac warten. Dieser prüft, ob die Karte noch gültig ist, und bildet die Antwort auf die ursprüngliche confirm- oder cancel-Aktion ab. Das Telefon erteilt keine dauerhafte Befehlsfreigabe. Spracheingabe kann einen zu bestätigenden Text erzeugen, ersetzt aber keine Zustimmung.

Seit 0.1.61 gibt es überall eine einzige Freigabekarte (Chatfenster, Posteingang, Island und iPhone). Das Telefon zeigt die eigene Frage der Karte, entnommen aus ihrem Titel, und was ihr Ja abdeckt. Es antwortet einmal oder für diese Aufgabe, wo das die erste Auswahlmöglichkeit der Karte ist (Karten für eine App, eine Website oder einen Shortcut: Die Überschrift endet dann mit „(for this task)“), und nie „In diesem Gespräch“ oder „Immer“. Eine Karte wartet auf dem Mac 30 Minuten (vor 0.1.61 waren es 5); der Ablauf der Zeit wird als expired gemeldet, was Arslan als „niemand hat geantwortet“ behandelt, nicht als Ablehnung. Eine Karte, die darum bittet, eine neue Fähigkeit zu installieren, erreicht das Telefon nie. Antwortet zuerst der Mac (in einem Fenster, im Posteingang oder in der Island), trägt das approval.result des Telefons answered_on_mac.

Dateien, laufende Unterhaltungen und Kurswechsel vom Telefon aus

Das sind additive Protokolltypen (Abschnitt 5.7 des Protokolldokuments); ein Mac ohne sie antwortet mit unknown_type, und der Mac sendet die neuen Ereignisse nur an ein Telefon, dessen hello-Fähigkeiten sie angefordert haben.

• Dateien vom Telefon (0.1.61). Eine Datei oder ein Foto, das von Arslan für iPhone gesendet wird (bis zu 20 MiB, höchstens 10 pro Nachricht), wird wie jedes Asset geprüft und auf dem Mac im Arbeitsordner unter Inbox/iPhone gespeichert, in einem Ordner pro Datum. Arslan liest sie zusammen mit der Nachricht; Bilder können als Bilder an das Modell gehen. Treffen nicht alle Dateien einer Nachricht innerhalb von 120 Sekunden ein, wird sie nicht ausgeführt, und das Telefon kann sie erneut senden.
• Laufende Unterhaltungen (0.1.61). Der Mac hält seine 20 neuesten Unterhaltungen und jede mit einer laufenden Aufgabe verknüpft, sodass das Telefon sie auflistet und Antworten, Fortschritt und Karten verfolgt, während Arslan arbeitet. Das Telefon kann eine Unterhaltung löschen (die Remote-Unterhaltung wird nie gelöscht). Ein Verlauf, der für eine Nachricht zu lang ist, lässt seine ältesten Nachrichten weg und sagt, dass er gekürzt wurde.
• Antworten, während sie geschrieben werden (0.1.63). Für ein Telefon, das darum gebeten hat, trifft die Antwort als partial-Ereignisse ein, die die gesamte bisherige Antwort tragen, höchstens einmal pro Sekunde und nicht über 100 KB hinaus; die endgültige Nachricht ersetzt sie. Am Mac getippte Wörter werden auf dem Telefon als vom Mac stammend gekennzeichnet gezeigt und lassen es nie klingeln.
• Kurswechsel (0.1.63). Eine Nachricht, die gesendet wird, während eine Antwort läuft, erreicht diese Antwort bei ihrem nächsten Schritt, statt zu warten; das iPhone, das Mac-Fenster und Halten-zum-Sprechen tun dies alle. Während die Antwort ihre Schlussantwort schreibt, gibt es keinen Schritt mehr, die Nachricht läuft also direkt danach. Bekannte Grenze in 0.1.63: Eine im Mac-Fenster während einer Antwort hinzugefügte Nachricht erscheint auf dem iPhone erst ab der nächsten Antwort, und das iPhone zeigt weiterhin „Queued behind the current turn“, nachdem seine eigene Nachricht hinzugefügt wurde.
• Dateien an das Telefon (0.1.63). Wenn Sie um eine Datei bitten (Screenshot, Diagramm, Export, Dokument), hängt Arslan sie an seine Antwort an: eine Dateikarte im Mac-Fenster und die Datei selbst auf dem iPhone, unter dem Limit von 20 MiB.

Abbildung von Freigabemerkmalen auf bestehende Aktionen; Bereinigung beim Entfernen oder erneuten Koppeln eines Telefons; Status, Fähigkeitsfelder, Eingang für Dateien vom Telefon und laufende Unterhaltungen; laufende Verknüpfungen, Dateien vom Telefon und Teilantworten; Unabhängige Protokollreferenz; Öffentlicher Auslieferungsstand von 0.1.54.

11 / Prüfung und SoftwareauslieferungVon lauffähigem Quellcode zur installierbaren und aktualisierbaren App

Die Auslieferungseinheit einer Desktopsoftware ist das Anwendungspaket. Python-Module, Systemwerkzeuge und alte Datenbanken aus der Entwicklungsumgebung können ein Paket mit fehlenden Ressourcen scheinbar funktionsfähig machen. Arslan trennt die Prüfung deshalb in Quellcode, Plattform, gebündelte Artefakte, frische Nutzerumgebung und Distribution. Dieses Kapitel dokumentiert den Ablauf von v0.1.63 und die zugehörigen Release-Belege.

CI prüft Verhalten, Plattform und Abhängigkeitsgrenzen

Bei macOS genügt nicht allein der pytest-Exitcode. Die Pipeline wertet JUnit aus und verlangt, dass 60 festgelegte Plattformfälle tatsächlich ausgeführt werden – ohne übersprungene oder fehlgeschlagene Tests. Fehlen Abhängigkeiten und werden dadurch alle Fälle übersprungen, wird die Prüfung ebenfalls nicht bestanden. Python und Rust teilen Hands-Vertragsbeispiele. Mac, iOS und eine unabhängige Python-Referenz verwenden gemeinsame Bridge-Testvektoren. So lassen sich Parameterabbildung, Signaturen, Empfängerprüfung, Manipulation und Replay sprachübergreifend abgleichen.

Die Aussagekraft bleibt begrenzt: Eine Swift-Typprüfung validiert keine Mikrofonberechtigung, ein Linux-Unit-Test keinen macOS-Kernel und ein simuliertes Postfach kein produktives CloudKit. Testzahlen sind auch keine Gesamtdeckungsquote. Überlappende Testsuiten dürfen nicht zu einer Zahl unabhängiger Szenarien addiert werden.

Vier CI-Gruppen und Prüfung tatsächlicher Ausführung; Sprachübergreifendes Hands-Vertragsbeispiel; Bridge-Referenzimplementierung.

Ein Release beginnt beim exakten Quellcode-Commit

Der Release-Workflow fragt ab, ob für genau die zu veröffentlichende SHA eine erfolgreiche CI vorliegt. Der Erfolg eines anderen Commits genügt nicht. Der Build verwendet durch Lockdateien gebundene Abhängigkeiten. Python wird ausdrücklich als eigenständiger, von uv verwalteter Interpreter gewählt, damit der Runner nicht zufällig einen Framework-Build verwendet. PyInstaller bündelt das Backend als onedir; statische Frontendressourcen sowie Swift- und Rust-Helper werden mit der Tauri-App zusammengestellt.

Signierung und Notarisierung erfüllen unterschiedliche Aufgaben. Eingebettete Mach-O-Dateien müssen zuerst signiert werden, bevor die äußere App sie umschließt. Für die Distribution werden Developer ID, Hardened Runtime und Zeitstempel verwendet. Das DMG wird bei Apple zur Notarisierung eingereicht, anschließend wird das Ticket per staple angeheftet und Gatekeeper prüft das Ergebnis. Das Buildskript erlaubt weiterhin unsignierte Entwicklungspakete und Warnpfade bei teilweise fehlenden Zugangsdaten. Ein erfolgreicher Build erfüllt deshalb nicht automatisch alle Voraussetzungen öffentlicher Distribution; beim offiziellen Release müssen die tatsächlichen Artefakte geprüft werden.

Für das Updatemanifest gelten eigene Bedingungen: Tag und Tauri-Version müssen übereinstimmen. Ein entsprechendes Manifest entsteht nur mit Updater-Signatur. Der Ablauf erzeugt zunächst ein GitHub Draft Release. Erst nach der offiziellen Veröffentlichung sehen installierte Apps das Update bei einer späteren Prüfung.

Prüfung der exakten SHA, Versionsabgleich und Draft Release; Bündelung, Zusammenstellung, Signierung, Notarisierung und Rückfallpfade; PyInstaller-Abhängigkeiten und Ressourcen.

Die Neuinstallationsabnahme startet unmittelbar das Anwendungspaket

fresh_install_check.py startet mit temporärem HOME und minimaler Umgebung das tatsächliche arslan-desktop im Paket. Es startet nicht stellvertretend den Dienst aus einer Quellcode-venv. Geprüft werden unter anderem, dass keine Nutzerdatenbank oder geheimen Dateien im Paket liegen, die Erstinitialisierung, Tokenerzeugung und Dateirechte, Ablehnung nicht authentifizierter Anfragen, ein echter WebSocket-101-Handshake sowie korrekter Abruf des Frontend-JavaScripts. HTTP 200 kann lediglich die SPA-Fallbackseite sein; eine Ressourcenprüfung darf sich daher nicht auf den Statuscode beschränken.

Dasselbe Skript prüft native OCR, eingebettete Helper, Bridge-Selbsttest und zugehörige Signaturen. In einem früheren gebündelten Paket fehlte eine dynamisch geladene WebSocket-Abhängigkeit: Der Health-Endpunkt funktionierte, der Chat konnte die Verbindung jedoch nicht hochstufen. Erfolgreicher Import, laufender Dienst und mitgelieferte Kernfunktion sind also drei unterschiedliche Nachweise.

App-Start und Paketabnahme; Explizite Aufnahme dynamischer WebSocket-Abhängigkeiten.

Nutzer starten die Updateinstallation; der Download wird verifiziert

Der Tauri-Updater findet Updates über die öffentliche latest.json und prüft die Archivsignatur mit dem in die App einkompilierten öffentlichen Schlüssel. Einmal beim Start wird geprüft; zusätzlich ist eine manuelle Prüfung im Menü möglich. Diese Version besitzt keinen Timer für regelmäßige Prüfungen. Bei einer neuen Version erscheint ein Hinweis. Erst nach dem Installationsklick folgen Download, Signaturprüfung, Austausch und Neustart. Eine fehlgeschlagene automatische Prüfung kann auf eine vorübergehend fehlende Verbindung zurückgehen; ein Installationsfehler muss dem Nutzer dagegen klar gemeldet werden.

Die frühen Versionen 0.1.0/0.1.1 registrierten nur das Updater-Plugin, riefen die Prüffunktion aber nicht aktiv auf und konnten deshalb neue Versionen nicht automatisch entdecken. Die aktuelle Implementierung verbindet Prüfung, Installationsbereitschaft, Downloadfehler und Neustart zu einem ausdrücklichen Ablauf. Eine vorhandene Signaturkonfiguration bedeutet noch nicht, dass dieser Ablauf ausgelöst wurde.

Zustände für Prüfung, Installation und Neustart; Updateadresse und öffentlicher Schlüssel.

Auf welche Artefakte sich die Auslieferungsbelege von 0.1.63 beziehen

Die GitHub-Actions-Läufe zum Release-Commit zeigen: Der Release-Quellstand ist 9bbb6ad6 auf main; die CI auf main bestand beim ersten Versuch (Run 40502155919), einschließlich der 60 festgelegten Plattformfälle des macOS-Jobs ohne übersprungene Tests; im Backend bestanden 9.469 Tests, 124 wurden übersprungen. Das Pushen des Tags startete keinen eigenen CI-Lauf, deshalb nutzte das Gate den Lauf auf main für denselben Commit. Der Release-Workflow (Run 40505601007) bestand Quellprüfung, Build und Veröffentlichung; das DMG wurde zur Notarisierung angenommen, das Ticket angeheftet und von Gatekeeper akzeptiert. Der Fresh-Install-Test der ausgelieferten App meldet 92 bestandene und 0 fehlgeschlagene Prüfungen, einschließlich der Annahme der Verbindung des signierten Backends durch Hands und des Bridge-Selbsttests.

Die beiden Releases davor: 0.1.61 wurde aus main bei fb6d7230 erstellt (CI auf main Run 38489348597, Tag-CI Run 38498094635, Release Run 38498094628; 54 Plattformfälle; Backend 8.466 bestanden und 124 übersprungen; Fresh-Install 89/0). 0.1.62 wurde aus release/0.1.62 bei a4fca23b erstellt (Branch-CI Run 39112567104, Tag-CI Run 39114206598, Release Run 39114206588; 55 Plattformfälle; Backend 8.747 bestanden und 125 übersprungen; Fresh-Install 89/0). Beide bestanden beim ersten Versuch, wurden notarisiert, mit dem Ticket versehen und von Gatekeeper akzeptiert.

Die geprüften Objekte unterscheiden sich, und die Aufzeichnungen benennen das. Die öffentlichen Notes zu 0.1.63 sagen, dass auf einem Release Candidate eine kurze Liste von Prüfungen von Hand durchgegangen wurde und dass zwei davon nicht bestanden (eine dritte Folgebearbeitung, die mehr änderte als verlangt, und eine einzeilige Änderung in einer langen Datei über das Terminal); sie sagen nicht, dass genau das DMG von 0.1.63 von Hand installiert und vollständig bedient wurde, und dieses Dokument tut es auch nicht, ebenso wenig einen vollständigen Durchlauf vom iPhone zum Mac mit der ausgelieferten App. Die Notes zu 0.1.61 und 0.1.62 enthalten keinen manuellen Durchlauf auf einem echten Mac, auf den sich dieses Dokument stützt. Zum Vergleich: Die Verification von 0.1.53 dokumentierte einen Durchlauf auf einem echten Mac, bei dem Hands eine Notiz in Notes erstellte und wieder las, während eine Freigabe 36 Sekunden lang wartete – mit dem Build-only-Paket von 43751254, nicht mit dem finalen DMG. Automatische Paketabnahme, Funktionstest eines früheren Builds und manuelle Abnahme des exakten Distributionspakets müssen getrennt benannt werden und ersetzen einander nicht.

12 / Tests und ValidierungWoran sich erkennen lässt, ob eine Aufgabe richtig erledigt wurde

Dass eine Aufgabe beendet wurde, eine Datei geöffnet werden kann und ein Bericht inhaltlich richtig ist, sind drei unterschiedliche Feststellungen. Arslan dokumentiert mit Ausführungsprotokollen, was geschehen ist, prüft anhand von Artefakten und Verträgen die bestimmbaren Eigenschaften und untersucht die Modellleistung anschließend mit realen Aufgaben. Eine bestandene Ebene ersetzt keine andere.

„Erledigt“ zuerst in überprüfbare Belege zerlegen

Das Abnahmesystem unterscheidet regelbasierte Prüfungen, Modellbewertungen und menschliche Kontrolle. Text, JSON, Dateiintegrität, Bildabmessungen und tatsächliche Ausführungsergebnisse lassen sich deterministisch prüfen. Modellbewertungen dürfen nur geeignete Aspekte beurteilen und nicht eine ausgebliebene Prüfung nachträglich als bestanden markieren. Erfolgreiches Parsen belegt eine lesbare Struktur, ein Quellenabrufprotokoll den Empfang von Inhalten. Beides beweist nicht automatisch sachliche Richtigkeit oder visuelle Qualität.

Grenzen von Abnahmeregeln und Artefaktprüfungen; 0.1.53: Unvollständige Aufgaben zeigen ausdrücklich Not done.

Testebenen: Jede beantwortet eine eigene Frage

Die Zuverlässigkeitsarbeit im September 2026 stellte beispielsweise 30 feste Verträge ohne externe Modellkosten bereit. Dabei wurden Speicher-, Abbruch-, Artefakt-, Backup- und Berechtigungscode tatsächlich ausgeführt, allerdings mit deterministischen Provider-Doubles. Das sind Belege für technische Verträge, keine 30 Ende-zu-Ende-Aufgaben mit echten Modellen. Spätere kostenpflichtige Bewertungen gehören zu einer anderen Belegebene und dürfen nicht in dieselbe Erfolgsquote eingehen.

Tests müssen auch belegen, dass sie tatsächlich ausgeführt wurden. Die macOS-CI von v0.1.63 wertet JUnit-Berichte aus und verlangt, dass 60 festgelegte Plattformfälle tatsächlich laufen und keiner übersprungen wird. Die Python- und Rust-Seiten von Hands verwenden gemeinsame Vertragsbeispiele, beide Bridge-Seiten gemeinsame Protokollvektoren. Für wichtige Schutzmaßnahmen beschädigen Mutationstests vorübergehend die Regeln und prüfen, ob die Tests fehlschlagen. So lassen sich Fälle erkennen, die nur die sichtbare Implementierung bestätigen, ohne das Verhalten wirksam abzusichern.

Technische Verträge und Modellqualität unterscheiden; Anzahl der Plattformfälle und Prüfung auf übersprungene Tests; Regressions- und Mutationstests für Quellenprüfung.

Release-Validierung muss an Quellcode und Artefakt gebunden sein

Die Fresh-install-Prüfung startet die App mit einem isolierten, neuen HOME und prüft Authentifizierung, den echten WebSocket-101-Handshake, Frontend-Ressourcen, OCR und Helper. Ein HTTP-200-Ergebnis des Health-Endpunkts allein genügt nicht: Frühere Pakete konnten trotz laufendem HTTP-Dienst überhaupt keine Chatverbindung herstellen.

Das Release v0.1.63 entspricht Commit 9bbb6ad6: Die CI auf main war beim ersten Versuch erfolgreich (Run 40502155919; das Pushen des Tags startete keinen eigenen CI-Lauf); Quellcodeprüfung, Build und Release-Schritt des Release-Workflows (Run 40505601007) waren erfolgreich; das DMG wurde zur Notarisierung angenommen und mit dem Ticket versehen, Gatekeeper akzeptierte es. Die Fresh-install-Prüfung der ausgelieferten App ergab 92 bestanden, 0 fehlgeschlagen, einschließlich Hands-Start und Bridge-Selbsttest. (0.1.61 und 0.1.62 bestanden jeweils mit 89 von 89: Läufe Run 38498094628 und Run 39114206588. 0.1.53 benötigte wegen einer reihenfolgeabhängigen Testschwankung einen zweiten CI-Versuch; 0.1.54 behob die Ursache – Tests, die eine gemeinsame Datenbanksitzung durchsickern ließen – und ergänzte eine Schutzprüfung, die jeden Test mit diesem Verhalten scheitern lässt.)

Die Belege zur Interaktion auf echter Hardware stammen aus einem anderen, ausdrücklich benannten Build.Im Notes-Test erstellte ein Hintergrundjob über Hands eine Notiz und las sie zurück. Die erste Freigabekarte konnte nach 36 Sekunden Wartezeit noch fortgesetzt werden. Die Dateiumbenennung erfolgte mit mv, ohne das Finder-Fenster zu bedienen. Diese Tests nutzten ein früheres Build-only-Paket aus Commit 43751254, das sich vom veröffentlichten Commit nur in Versionsnummer und Dokumentation unterscheidet. Es hat nicht denselben SHA wie die endgültige Veröffentlichung. Die Versionshinweise von 0.1.60 legten außerdem offen, dass das exakte endgültige DMG vor der Veröffentlichung nicht manuell installiert und vollständig durchgespielt wurde. Installationsprüfungen und der Notes-Praxistest des früheren Builds sind daher getrennt darzustellen.

Der eigene Test von 0.1.63 vor dem Release verfehlte zwei Hürden, und die Notes sagen das. Neun Aufgaben, je drei Läufe, auf DeepSeek und auf Claude, mit eingeschaltetem „Nur bei riskanten Befehlen fragen“: Die Aufgabe „einen anderen Weg finden nach einem abgelehnten Löschen“ bestand auf Claude 0 von 3 (in 0.1.62 3 von 3), weil ein Löschen per Name nach dem Wechsel in den Arbeitsordner absichtlich ohne Karte lief, da „Diesen Zug rückgängig machen“ die Dateien zurückbringen kann; und die Aufgabe „drei Folgebearbeitungen an einem Dokument“ bestand auf DeepSeek 1 von 3 und auf Claude 0 von 3, weil die Prüfung einen auf unter 60 % seiner Länge gekürzten Abschnitt verlangt und die Aufgabe nur darum bittet, ihn kürzer zu machen (die Prüfung blieb bestehen). Die ausgelieferte Voreinstellung, vor jedem neuen Befehl zu fragen, ist nicht das, was diese Runden ausführten. Ergebnisse dieser Art zeigen Schwachstellen auf; sie sind kein Ranking.

Release Notes zu 0.1.63; Release-Pipeline; Installationsprüfung; Paketierung und Signatur.

Daten realer Aufgaben: Vergleichsergebnisse und Schwächen bewahren

Die Bewertung von 0.1.51 am 3. Oktober 2026 verwendete deepseek-v4-pro im Vergleich mit Hermes in derselben Versuchsrunde. Vier Aufgabentypen wurden jeweils dreimal ausgeführt. „Abnahme bestanden“ bedeutet checker score=3 und ist nicht mit dem Laufstatus done gleichzusetzen. Kosten und Zeit sind Mittelwerte aus den drei Läufen je Typ einschließlich Fehlschlägen; die Kosten basieren auf dem damaligen Nebentarif. Die Zeit reicht vom Beginn der ersten bis zum Ende der letzten Modellanfrage. Sie ist weder die Ende-zu-Ende-Dauer der gesamten Aufgabe noch reine Modellrechenzeit.

Diese Versuche helfen, Verbesserungsmöglichkeiten zu erkennen, rechtfertigen aber keine allgemeine Produktrangliste. Modell, Aufgabe, Umgebung und Freigabepolitik beeinflussen das Ergebnis. In dieser Runde war zudem das Guthaben zwischenzeitlich aufgebraucht; die Läufe wurden anschließend fortgesetzt. Vier fehlgeschlagene Anfragen ohne Kosten wurden aus dem zur Zeitmessung verwendeten usage log entfernt; das ursprüngliche Protokoll blieb erhalten. Die öffentlichen Versuchsaufzeichnungen dokumentieren diese Rahmenbedingungen, die bei der Auswertung mitberücksichtigt werden sollten.

Auch Versionsvergleiche erfordern Zurückhaltung: Die Erinnerungsstichprobe stieg von 1/3 in 0.1.49 auf 3/3 in 0.1.50; in dieser Phase wurden Wiederherstellungswege und Kontextzustand verbessert. Zwischen den Versionen änderten sich jedoch mehrere Dinge. Die gesamte Differenz lässt sich deshalb nicht streng einem einzigen Prompt oder Modul zuschreiben.

Versuchsmethode und Ablauf für 0.1.51; Zusammenfassung der vier Aufgaben; Zwischenbewertung der Wiederherstellungswege.

Auch Modellbewertungen müssen geprüft werden

Bei der Kalibrierung der Quellenprüfung in 0.1.41 entstanden zu 13 Berichten 14 Hinweise: 1 korrekt, 2 grenzwertig und 11 falsch; zugleich blieben zwei vorab registrierte bekannte Fehler unerkannt. Die Funktion blieb deshalb standardmäßig abgeschaltet. Ein weiteres Modell aufzurufen ergibt nicht automatisch einen zuverlässigen Faktenprüfer. Ein gültiges Format und vorhandene Anker garantieren keine berechtigte Kritik.

Die Validierung des Erfahrungslernens in 0.1.52 zeigt eine andere Grenze: Nach einer abgelehnten AppleScript-Aktion wurde die Erfahrung gespeichert, abgerufen und beim nächsten Versuch direkt EventKit gewählt. Das belegt einen Einfluss der Erfahrung auf die Ausführung. Nachfolgende Skriptänderungen und Prüfungen verursachten jedoch zusätzliche Aufrufe; eine Beschleunigung wurde nicht gemessen. Um die Effizienzsteigerung durch die Erfahrung selbst zu beurteilen, sind gepaarte Wiederholungen derselben Aufgabe mit und ohne Erfahrung nötig. Die damalige Aufzeichnung weist ausdrücklich darauf hin, dass dieser faire Geschwindigkeitsvergleich noch nicht durchgeführt wurde.

Belastbarere Qualitätsaussagen erfordern vorab festgelegte Aufgaben, Ergebnisse und Prüfmaßstäbe, Aufzeichnungen zu Modell und Konfiguration, Aufrufspuren, tatsächlichen Kosten und Fehlerursachen sowie unabhängige menschliche Bewertungen zur Kalibrierung der Modellnoten. Formal ungültige Bewertungen, nicht ausgeführte Prüfungen und nicht verfügbare Belege müssen ihren eigenen Status behalten. Sie dürfen nicht für eine schönere Zusammenfassung als bestanden zählen.

Öffentliche Kalibrierungsergebnisse der Quellenprüfung; Belegte und unbelegte Aspekte des Erfahrungslernens; Bewertungsbedingungen für belastbarere Qualitätsaussagen.

13 / Technische WeiterentwicklungVon vorhandenen Fähigkeiten zu verlässlicheren Ergebnissen

Arslan verfügt über drei Grundlagen: Ausführung, fortlaufende Aufgaben und Gedächtnis. Als Nächstes ist zu prüfen, ob diese Fähigkeiten auch in komplexeren Situationen konsistente Zustände und verlässliche Ergebnisse ermöglichen und dabei die Kontrolle beim Nutzer belassen. Die folgende Grafik trennt vorhandene Implementierungen, noch zu validierende Bereiche und mögliche technische Weiterentwicklungen. Sie dient der technischen Diskussion und ist keine terminierte Veröffentlichungszusage. Das Kapitel gibt den Stand von v0.1.63 wieder; was für 0.1.64 geplant ist, ist als geplant gekennzeichnet, nicht als gebaut.

Für 0.1.64 geplant (nur ein Plan, nicht gebaut; aus dem freigegebenen Plan für 0.1.64): Zuerst eine Sandbox für Befehle, Python und installierte Werkzeuge, die standardmäßig alles verweigert. Danach kommt „Nur bei riskanten Befehlen fragen“ zurück. Anschließend ein optionaler Modus „Auto“, in dem ein prüfendes Modell einen Teil der Karten beantwortet: Er ist standardmäßig aus, erscheint nur, wenn er vorab festgelegte Mindestwerte erreicht, und genehmigt nie etwas, das die Sandbox verlässt, etwas nach außen sendet oder ins Netz geht. Es gäbe fünf Modi, pro Unterhaltung neben dem Eingabefeld gewählt: Planen, Bei jedem Schritt fragen, Automatisch bearbeiten, Voller Zugriff und Auto; die Einstellungen behielten nur die Vorgabe für neue Unterhaltungen. Geplante Aufgaben dürften wieder nur lesende Befehle ausführen. Bis dahin fragt jeder neue Befehl zuerst, und geplante Aufgaben führen keine Befehle aus. Eine Seite, die gemerkte Antworten auflistet und rückgängig macht, und eine Einstellung für erlaubte Ordner werden erwogen, stehen aber nicht im Plan. Die Notes zu 0.1.63 nennen außerdem zwei Korrekturen für bekannte Grenzen: Ein Löschen nach einem Ordnerwechsel im selben Befehl wird fälschlich als innerhalb des Arbeitsordners behandelt, und eine einzeilige Änderung in einer langen Datei läuft über das Terminal statt über das Bearbeitungswerkzeug.

Ergebnisse bei realen Aufgaben

Ein fester Aufgabensatz sollte die Vollständigkeit der Suche, den Zusammenhang zwischen Zitaten und Schlussfolgerungen, die Nutzbarkeit von Dateien, die tatsächliche Wirkung von Systemaktionen und einen ehrlichen Abschluss bei Fehlschlägen prüfen. Vorhandene Vergleiche haben Schwächen bei Rechercheaufgaben aufgezeigt, und der Test von 0.1.63 vor dem Release (neun Aufgaben, je drei Läufe, auf DeepSeek und Claude) verfehlte zwei seiner eigenen Hürden: einen anderen Weg finden nach einem abgelehnten Löschen (Claude 0 von 3, weil ein Löschen innerhalb des Arbeitsordners mit „Nur bei riskanten Befehlen fragen“ ohne Karte läuft) und drei Folgebearbeitungen an einem Dokument (DeepSeek 1 von 3, Claude 0 von 3). Bevor weitere Werkzeuge hinzukommen, sollte geklärt werden, an welcher Stelle etwas nicht gefunden, nicht vollständig gelesen, nicht geprüft oder nicht korrekt geliefert wurde. Das hilft gezielter, die Abschlussquote zu verbessern.

Wiederherstellung und Konsistenz über Gerätegrenzen

Netzwerkwiederholungen, doppelte Nachrichten, App-Neustarts und Abbrüche durch Nutzer können gleichzeitig auftreten. Weitere Prüfungen können sich auf stabile fachliche IDs, den Schutz endgültiger Zustände vor alten Nachrichten, das Verhalten nach abgebrochenen Freigaben und die Prüfung unklarer Seiteneffekte konzentrieren. Gezielte Abstürze und negative Protokollfälle sollen klären, was automatisch verarbeitet werden kann und wann erneut eine Bestätigung des Nutzers erforderlich ist. Ein Teil ist bereits ausgeliefert: Seit 0.1.63 wird ein Checkpoint gesichert, bevor eine Runde den Arbeitsordner erstmals ändert, und „Diesen Zug rückgängig machen“ stellt die Dateien wieder her und entfernt die Runde. Das ist begrenzt: Es sichert nur einen Ordner mit höchstens 20.000 Dateien und 5 GB (ohne Python-Umgebungen, node_modules, Build-Ausgaben und Python-Caches) und sagt sonst „Not saved“; es deckt nur den Arbeitsordner ab, nicht Wirkungen außerhalb davon.

Messbarer Nutzen des Lernens

Gespeicherte Erfahrungen sind erst der Anfang. Unter gleichen Aufgaben- und Modellbedingungen müssen Abschlussquote, Aufrufkosten, Zeitbedarf und Fehlverhalten wiederholt mit und ohne Erfahrungen verglichen werden. Ebenso ist zu prüfen, ob veraltete Erfahrungen korrigiert werden, ob externe Texte sie verfälschen können und ob gelöschte Erfahrungen weiterhin abgerufen werden.

Aufwand für Plattformen und Erweiterungen

Tauri stellt einen plattformübergreifenden Host bereit. Seatbelt, Vision, Accessibility, Apple Events und CloudKit haben jedoch plattformspezifische Eigenschaften. Eine Erweiterung auf andere Desktop-Systeme erfordert Ersatz und Validierung dieser Fähigkeiten; eine erfolgreiche Kompilierung für eine andere Plattform belegt noch keine vollständige Übertragung der Produktfunktionen. Mehr externe Werkzeuge bedeuten zudem mehr Zugangsdaten, Berechtigungen und Fehlermöglichkeiten.

Diese technischen Perspektiven beruhen auf vorhandenen Implementierungen und Testergebnissen. Maßgeblich für konkrete Prioritäten und Termine sind spätere offizielle Versionshinweise.

14 / GlossarVon Fachbegriffen zur konkreten Implementierung

Die Begriffe unterscheiden verschiedene Mechanismen. Die folgenden Tabellen erklären sie knapp und ordnen sie Arslans Implementierung zu. Historische Mechanismen sind ausdrücklich gekennzeichnet.

KI und Kontext

Softwarearchitektur, Zustand und Zuverlässigkeit

Betriebssystem, Sicherheit und Auslieferung

Das heutige System besteht überwiegend aus einem lokal geschichteten Monolithen und eigenständigen Helpern. SQLite und prozessinterne asynchrone Planung passen zur Installation und zum Betrieb eines persönlichen Desktop-Produkts. Die Begriffe sind in diesem Bereitstellungsmaßstab zu verstehen.

15 / Häufige FragenWas beim Einsatz und Verständnis von Arslan leicht verwechselt wird

16 / VersionsanhangVollständiger Änderungsverlauf von 0.1.0 bis 0.1.63

Dieser Anhang umfasst die 64 Versions-Tags im stabilen Nummernformat von v0.1.0–v0.1.63 sowie den Vorschauzweig von 0.1.40 und die Betas von 0.1.59. Nach Abgleich der öffentlichen Veröffentlichungen am 2026-10-27 sind auf GitHub derzeit 63 stabile Releases und 6 Vorabversionen sichtbar, insgesamt 69. Für v0.1.39 existiert ein Versions-Tag, aber derzeit kein entsprechendes öffentliches Release.

Die neueste stabile Version v0.1.63 wurde nach Pekinger Zeit am 2026-10-27 um 22:26:31 veröffentlicht; der ursprüngliche UTC-Zeitpunkt ist 2026-10-27 um 14:26:31. Die folgende Tabelle verwendet einheitlich das Datum nach Pekinger Zeit. Abgesehen vom ausdrücklich gekennzeichneten Tag-Datum von v0.1.39 stammen alle Daten aus dem Release-Feld published_at; Commit-Daten ersetzen keine Veröffentlichungsdaten.

Vorschauzweig 0.1.40: Eine Nummer bedeutet noch keine Veröffentlichung

Öffentliche Vorabversionen sind beta.3, beta.5 und beta.6. Für beta.1 und beta.2 bestehen Kandidaten-Tags und Aufzeichnungen. beta.4 wurde nicht separat veröffentlicht; seine Änderungen gingen in beta.5 ein. Die sechs Nummern stehen daher nicht für sechs öffentliche Vorabveröffentlichungen an Nutzer.

beta.2 zeigt, weshalb der Veröffentlichungsstatus getrennt dokumentiert werden muss: Signierter Build und Installationsprüfungen bestanden, die CI des Tags jedoch nicht; der Entwurf untersagte die Veröffentlichung ausdrücklich. beta.3 ergänzte anschließend die Vorgabe, dass für den zu veröffentlichenden Commit erfolgreiche CI vorliegen muss. beta.5 erklärt zudem, dass die Änderungen der unveröffentlichten beta.4 enthalten sind und beta.4 nicht zuvor installiert werden muss.

Eine Änderung zurückverfolgen

Einträge stabiler Veröffentlichungen verlinken das jeweilige Release, v0.1.39 den Versions-Tag. Die Zusammenfassungen verbinden offizielle Versionshinweise mit den Commits zwischen benachbarten Tags. Funktionen, die nur in Planungsdokumenten stehen, werden nicht als ausgeliefert dargestellt. Für Implementierungsprüfungen sollte der jeweilige Tag oder Release-Commit fixiert werden; das veränderliche main eignet sich nicht zur Erklärung früherer Versionen.

Einige Release-Entwürfe im Repository enthalten weiterhin HOLD-Vermerke oder Hinweise aus der Zeit vor dem Build. Sie erklären den damaligen Prozess, reichen aber allein nicht zur Beurteilung aus, ob eine Version heute öffentlich veröffentlicht ist. Der öffentliche Release-Status und die abschließenden Validierungsaufzeichnungen müssen gemeinsam geprüft werden. „Derzeit kein öffentliches Release“ beschreibt den zum Zeitpunkt der Prüfung sichtbaren Stand; laut den Release-Dokumenten gab es für v0.1.39 und beta.2 einmal unveröffentlichte Release-Entwürfe, die nicht mehr in der Release-Liste stehen.

Alle öffentlichen Releases; Versions-Tags; CI-Prüfung desselben Commits in beta.3; Hinweis von beta.5 zur unveröffentlichten beta.4; Aktuelle stabile Version.

17 / Versionsbasis und QuellcodezugängeAussagen der Dokumentation bis zu ihren Belegen zurückverfolgen

Diese Dokumentation beschreibt die Implementierung einer festgelegten Version und gleicht öffentliche Veröffentlichungen, Git-Tags und -Historie, den Quellcode des Release-Commits, Architekturentscheidungen und öffentliche Abnahmeunterlagen miteinander ab. Frühere Entwürfe erklären die Entwicklung; Verhalten, das späterer Code ersetzt hat, ist als historisch gekennzeichnet. Die Angabe zur eigenständigen Entwicklung mit KI-Unterstützung stammt vom Autor.

Die passende Implementierung zur Frage finden

1. Wie sich das Projekt entwickelt hat: Öffentliche Releases; Frühester nachverfolgbarer Commit; One Arslan; Einheitlicher Loop.
2. Wie das Programm startet: Desktop-Lebenszyklus; Einstiegspunkt des lokalen Dienstes; Agent-Einstiegspunkt; Werkzeugschleife.
3. Wie Modelle angebunden werden: Adapter; Werkzeugtrajektorie; Ausführungsbudget.
4. Wie Aufgaben gespeichert und wiederhergestellt werden: Aufgabenverträge; Zustand, Persistenz, Abgrenzung von Versuchen und Checkpoints; Abnahme; Ungültigmachen von Freigaben und Isolieren von Aufgaben nach einer Backup-Wiederherstellung.
5. Wie Erinnerungen genutzt und gelöscht werden: Persönlicher Kontext; Dokumentensuche; Erfahrungen; Gedächtnispersistenz; Versionierte Migrationen.
6. Wie Fähigkeiten erweitert werden: Integrierte Ausführer; Plugin-Manifest; MCP; Nur lesende Worker.
7. Wer Berechtigungen durchsetzt: Terminalrichtlinie; Befehlssandbox; Ausführung und Rückfallverhalten; Hands helper.
8. Wie sich das Telefon verbindet: Bridge-Protokoll; Bridge-Lebenszyklus; Abbildung von Ereignissen und Freigaben.
9. Wie bewertet und veröffentlicht wird: 0.1.51: Vergleich realer Aufgaben; 0.1.52: Abnahme; Installationsabnahme; Release-Workflow.
10. Open-Source-Herkunft und Rückmeldungen: Lizenz; Quellenangaben zu Drittanbietern; Richtlinie für Sicherheitsmeldungen; Projekt-Issues.

Diese Dokumentation beschreibt eine bestimmte Version und ihre überprüfbaren Grenzen. Für spätere Versionen sollten die jeweiligen Releases und der zugehörige Quellcode gemeinsam gelesen werden. Architekturrichtung, Entwurfsabsichten, Testumfang und offizielle Auslieferung werden getrennt erläutert, damit erkennbar bleibt, für welchen Bereich eine Aussage gilt.