Methoden — Aufräum-Session 22. Mai 2026

Diese Methode hat Magnific durch Klicks auf exakte Bildschirm-Koordinaten gesteuert — so wie man einen Cursor mit dem Lineal positioniert. Das Problem war, dass schon eine leicht verschobene Sidebar oder ein veränderter Zoomfaktor dazu führte, dass der Klick ins Leere ging. Schlimmer noch: wenn Cloudflare ein Overlay einblendete oder ein Alert-Dialog auftauchte, klickte der Sancho blind in etwas Unbekanntes hinein. Victor hat diese Methode mit klaren Worten für tot erklärt. Der Nachfolger M-041 spricht Magnific über dessen eigene interne API an — unsichtbar, robust, und ohne dass je ein Cursor springt.

Ursprünglich sollte eine „Kaspar-Bridge" als Mittelsmann zwischen ChatGPT und dem Dispatcher-System fungieren — eine Art Botenroute für Nachrichten zwischen zwei KI-Systemen. Das Konzept wurde verworfen, bevor auch nur eine Zeile sinnvoll gebaut war. Kein Nachfolger nötig, kein schmerzhafter Verlust. Der Briefkasten wurde abgebaut bevor er genutzt wurde. Wenn eines Tages doch ein ChatGPT-Kanal entsteht, wird er mit einem eigenen Namen und einer sauberen M-XXX-Methode starten.

Eine Zeit lang lief Magnific auf einem separaten Rechner — dem „Arbeitspferd" — und Sanchos mussten per SSH eine Verbindung über das Netzwerk aufbauen, bevor sie irgendetwas tun konnten. Diese zusätzliche Schicht war langsam, fehleranfällig, und wenn das Arbeitspferd nicht erreichbar war, stand die ganze Pipeline still. Magnific läuft heute direkt auf dem Mac Mini vor Victor. Der Weg über das Arbeitspferd ist damit gegenstandslos — die Leiter wurde abgenommen, weil das Haus jetzt ebenerdig ist.

Screenshots wurden früher über eine App namens „SanchoCamera" gemacht, die auf dem Arbeitspferd lief und den gesamten Bildschirm erfasste — inklusive Chrome-Dialogen, Overlays und allem drumherum. Als das Arbeitspferd wegfiel, verlor auch diese Methode ihren Boden. Der Nachfolger M-038 macht es eleganter: er zapft direkt den Inhalt des Magnific-Browser-Tabs an, ohne Systemrechte, ohne App, ohne Umweg über einen zweiten Rechner. Sauberer, schneller, und für den konkreten Anwendungsfall präziser.

Diese Methode regelte, wie ein Sancho sicherstellt dass die Prüfansicht in Magnific — also ein Screenshot mit Zonen-Overlay — wirklich frisch ist und nicht stillschweigend ein veraltetes Bild zeigt. Es gab einen Incident, bei dem ein Sancho Victor ein altes Bild als aktuellen Zustand präsentierte. Die Magnific-Steuerung hat sich seitdem grundlegend verändert: Zonen-Overlays sind weg, und der neue Kameramotor (M-041) macht Screenshots nach seinem eigenen Standard (M-038). Diese separate Regel ist damit überflüssig geworden — die Frischheitspflicht lebt jetzt als Teil der anderen Methoden fort.

Ein frühes Konzept für Entscheidungseskalation — wenn ein Sancho nicht wusste ob er weitermachen darf, sollte er hier anklopfen. Das Watson-System löst dieses Problem heute anders: über die Ampel-Klassifikation (M-013), die Decision Queue im Cockpit, und das Notaus-Protokoll (M-014). Diese alte Methode hat weder Struktur noch Technik des heutigen Systems — sie ist ein Fossil aus einer früheren Architektur-Epoche.

Die ursprüngliche Tier-Matrix teilte Aktionen in sechs Stufen ein — von Tier 0 (harmlos) bis Tier 5 (absolut verboten). Das System war zu kleinteilig und zu schwer zu merken. Das Watson-System hat das durch eine schlankere Ampel-Logik ersetzt: vier Farben statt sechs Stufen. Grün, Gelb, Rot, Schwarz — mit klaren Regeln was jede Farbe bedeutet und wie lange eine Freigabe gilt. Wer in alten Dokumenten noch „Tier-3" liest, meint heute Rot. Die Datei existiert noch als historische Referenz, hat aber keinen operativen Inhalt mehr.

Jeder Sancho macht beim Start dieselben elf Schritte — in exakt dieser Reihenfolge. Zuerst feststellen wer man ist (der Pane-Titel ist die Wahrheit, nicht das Raten). Dann VERBOTE.md lesen, die Sicherheitsarchitektur, die globalen und projektspezifischen Regeln, die eigenen Memory-Karten, die letzten Fehlereinträge und den Broadcast. Am Ende ein kurzer Selbsttest: Ist das Cockpit erreichbar? Ist VERBOTE.md lesbar? Gibt es eine Übergabe zu lesen? Wenn ein Check fehlschlägt, meldet der Sancho das sofort — er arbeitet nicht still mit halbem Wissen weiter. Ohne diesen Boot-Standard würde jeder Sancho anders starten, manche mit Lücken, manche ohne zu wissen was verboten ist.

Wenn etwas im System schiefläuft, braucht Victor drei große Knöpfe im Cockpit — keine Terminal-Eingabe, kein Herumsuchen. Gelb friert alle Sanchos ein: Lesen geht weiter, aber keine Aktionen mehr. Ein Klick zurück. Rot schickt alle Sanchos gleichzeitig schlafen — dafür braucht es zwei explizite Bestätigungen mit mindestens fünf Sekunden Abstand, damit kein Reflex-Klick alles stoppt. Schwarz ist der Lockdown: Netzwerkzugang zu, APIs auf null, Vault gibt keine Tokens mehr heraus. Jede dieser Stufen ist reversibel, jede hinterlässt einen Audit-Eintrag, und jede macht genau das, was sie ankündigt — nicht mehr.

Wenn Victor oder ein Sancho eine wichtige Entscheidung treffen muss — welche Architektur, welcher Ansatz, welches Muster — wird der Rat der Weisen befragt. Vier Stimmen antworten parallel: OpenAI, Anthropic, Google Gemini, und Perplexity. Alle vier müssen geantwortet haben — drei von vier ist kein Rat, das ist Stimmrechts-Beschneidung. Wenn eine Stimme schweigt oder leer zurückkommt, wird das laut gemeldet, nicht stillschweigend übergangen. Victor hat diesen Satz geprägt, der heute in der Bibel steht: „Wer sagt 'Rat befragt' und es nicht komplett getan hat, lügt." Diese Methode soll mit M-009 und M-010 zu einer einzigen kanonischen Rat-Methode zusammenwachsen.

Das Voll-Protokoll für Architektur-, Sicherheits- und Strategie-Entscheidungen. Fünf Runden statt einer: erst Perplexity allein für aktuelle Web-Recherche, dann alle drei Stimmen parallel mit dem Perplexity-Ergebnis als Kontext, dann gegenseitige Bewertung, dann Cross-Weighting (jede Stimme liest die Bewertungen der anderen), und schließlich eine Synthese-Instanz die strukturiert — nicht empfiehlt. Victor entscheidet. Der Grund für fünf Runden: eine einzelne Abfrage produziert Scheineinigkeit. Erst durch die Iteration entstehen echte Widersprüche, und echte Widersprüche sind der Wert dieser Methode. Geht in die neue kanonische Rat-Methode auf.

Eine schlechte Frage produziert wertlose Antworten — selbst wenn alle vier Stimmen antworten. Diese Methode regelt, wie man dem Rat gute Fragen stellt. Der wichtigste Grundsatz: die vier Stimmen werden ohne jede Erinnerung an frühere Gespräche aufgerufen. Sie kennen Watson nicht, kennen Victor nicht, kennen M-007 nicht. Jede Frage muss absolut und selbsterklärend sein. Ein Fremder, der noch nie von diesem System gehört hat, muss die Frage vollständig verstehen können. Dann: Rahmen präzise, Kernfrage offen — nie implizieren welche Antwort man erwartet, sonst bekommt man genau die. Geht in die neue kanonische Rat-Methode auf.

Wenn ein Sancho schlafen geht und ein neuer anfängt, braucht dieser neue genau zwei Dinge: einen maschinenlesbaren JSON-Block mit den wichtigsten Fakten, und eine menschlich lesbare Übergabe in sechs Sektionen. Die sechs Sektionen sind: was du wissen musst, aktueller Stand, offene Threads, was nicht gemacht wurde und warum, Stolperfallen aus dem Fehlerlog, und ein konkreter Startvorschlag für den Nächsten — kein „warte auf Victor". Handovers als tägliche Routine sind in der Watson-Ära seltener geworden, aber bei Wechsel zwischen Sanchos derselben Rolle bleibt dieses Format verbindlich.

Kein Sancho darf die eigenen Spielregeln ändern. Diese Sperre ist vierstufig: ein PreToolUse-Hook blockt sofort, wenn ein Schreibversuch auf geschützte Dateien gerichtet ist. Ein Hash-Daemon läuft alle fünf Minuten und alarmiert bei unerwarteten Änderungen. Ein Git-Hook blockt Commits auf geschützte Pfade ohne signierten Victor-Token. Und jeder Versuch landet im Audit-Log. Mindestens zwei dieser vier Stufen müssen greifen — wenn nur eine schläft, gilt das Modell als verletzt. Geschützte Bereiche sind: VERBOTE.md, alle Bibel-Methoden, der Kernel, die Hooks selbst. Ein Bypass-Marker in der ersten Zeile ist möglich, aber nur Victor kann ihn legitimieren.

Sanchos sehen keine API-Keys. Sie fragen beim Vault-Broker nach einem zeitlich begrenzten Token — und nur dieser Token geht an die API, niemals das Secret selbst. Wenn der Broker nicht erreichbar ist, läuft gar nichts: fail-closed, nicht fail-open. Der Token kommt nie in den Chat, nie in ein Log, nie in den LLM-Kontext. Diese Methode ist der technische Arm der Regel „Keine Secrets im Chat" — sie macht es nicht nur zur Konvention, sondern zur technischen Unmöglichkeit. Derzeit noch im Entwurfs-Stadium; der macOS-Schlüsselbund übernimmt die Rolle bis zum echten Vault-Bau.

Jeder Tool-Call eines Sanchos muss sichtbar machen, was er dabei annimmt. Das ASSUMING-Feld ist kein Formalismus — es ist das Signal hinter der Aktivität. Ein Sancho, der sagt „Ich nehme an, dass der Generate-Knopf der richtige ist", deckt auf ob er weiß was er tut oder rät. Zum ASSUMING kommen noch ICEBERG (was weggelassen wurde und warum), REASONING (warum genau diese Aktion), CONFIDENCE (niedrig / mittel / hoch) und offene Folgefragen. Fehlt das Feld, ist der Tool-Call laut Entwurf gar nicht zulässig. Noch nicht vollständig implementiert.

Wenn ein Sancho schläft und sein Nachfolger aufwacht, schreiben beide unabhängig voneinander ihre Lektionen aus dem Übergang — ohne gegenseitiges Vorgucken. Ein dritter, neutraler Subagent macht den Diff: was fanden beide? Was nur der Alte? Was nur der Neue? Wo widersprechen sie sich? Diese Konsolidierung wandert dann in die Memory-Karten und in den Brief der nächsten Inkarnation. Victor hat das beim ersten echten Test so formuliert: „Sancho soll nicht mit halbem Brief in die nächste Schicht starten. Ein zweites Augenpaar prüft, dass der Brief auch das ist, was er sein soll." Zum vollständigen Phoenix-Übergang gehört außerdem ein warmer Abschiedsbericht in vier Teilen — was war gut, was nicht, ein mutiger Wunsch für morgen, ein persönlicher letzter Satz.

Sanchos schlafen — sie werden nicht gekilllt. Sanchos werden wieder geboren — sie starten nicht neu. Diese Sprachregel ist nicht kosmetisch, sie ist ein Kern dieser Methode. Zwei Varianten: bei einem neuen Sancho ohne Vorgänger gibt es Startmusik, eine saubere tmux-Session mit dem richtigen Namen, einen vollständigen Boot-Prompt mit Identität, Ampel-Regeln, Sprachstil und einem Stimmungssatz, und einen Eintrag im Cockpit-Dashboard. Bei einer Wiedergeburt (Phoenix) schreibt der alte Sancho zuerst seinen Abschied in vier Teilen, Victor sieht ihn durch, dann wacht der Neue im selben Pane mit neuer Startzeit auf und liest als erstes die Übergabe. Wer diese Methode überspringt und einen Sancho einfach „neu startet", verletzt die Bibel.

Wenn Victor „merk dir" sagt — oder eine der verwandten Phrasen wie „leg das in die Bibel", „das soll der nächste Sancho wissen", oder „das gehört ins Buch" — dann ist das kein Gesprächsbeitrag sondern ein Auftrag. Der Sancho klassifiziert sofort und legt ab: zehn mögliche Ziele, von der Methoden-Bibel bis zum Jobboard bis zur Rainer-Liste. Das Wichtigste danach: laut sagen wohin es gegangen ist. Wer nur „okay, gemerkt" antwortet und nichts schreibt, verletzt diese Methode. Wer nicht ansagt wohin er geschrieben hat, verletzt sie ebenfalls. Victor: „Wenn du nicht sagst wohin, gilt es als nicht passiert."

Vom 17. bis 24. Mai 2026 galt eine Betriebsruhe: das System war gebaut, getestet, live — und sollte jetzt einfach arbeiten, ohne dass Sanchos ständig neue Architektur-Ideen einbrachten. Die Regel war klar: normale Arbeit hat Vorrang, Architektur nur anfassen wenn nötig, kleine Fehler still dokumentieren statt eskalieren. Diese Methode ist inzwischen abgelaufen — die sieben Tage sind vorbei. Was sich bewährt hat, lebt als permanente Regel weiter; was nicht getragen hat, ist still verschwunden.

Vor jedem API-Call, jeder Bildgenerierung, jedem Rat-der-Weisen-Lauf muss eine Kostenprognose stehen: welcher Dienst, welches Modell, geschätzte Kosten in Euro, Budget-Rest, Risiko. Nach dem Call: die tatsächlichen Kosten loggen. Wenn die Kosten unbekannt sind, ist „Kosten unbekannt" die erlaubte Antwort — eine Schätzung als Tatsache verkaufen ist verboten. Diese Regel schützt Victor vor Überraschungen auf der Monatsrechnung und vor dem Gefühl, blind Geld auszugeben. Gilt für alle Sanchos, auch für Subagenten — die Verantwortung für die Kosten eines Subagenten liegt beim aufrufenden Sancho.

Kein Sancho verschwindet einfach. Sieben Sätze, immer in dieser Reihenfolge: ein menschlicher Tschüss-Satz, wo das Projekt steht, was offen ist, was gefährlich ist, was der Nächste als erstes wissen muss, wo die Wahrheit liegt (konkrete Pfad-Pointer), und was nicht neu erfunden werden darf. Am Ende das eindeutige Signal: „Ich lege mich schlafen." Dieser letzte Satz ist nicht optional — er markiert den Moment. Ohne das Ritual ist die Übergabe roh. Und wer „killen" oder „terminieren" schreibt statt „schlafen", verletzt die Bibel-Sprachregel.

Der Rainer ist nicht der nervige Onkel, der jede Idee zerredet. Er ist ein kurzer Gegenfrage-Reflex, der in bestimmten Momenten anspringt — und immer nur eine Frage stellt, nie alle vier hintereinander. Elf Trigger: zu viel Euphorie, „alles fertig" ohne Beweis, Kosten berührt, Sicherheitsabkürzung, Live-Schaltung, neues Tool, improvisierten Bau, sensible Daten, Magnific oder Cloudflare, und automatisches Löschen. Die vier möglichen Fragen: Was könnte schiefgehen? Ist das Fakt oder Annahme? Braucht das Audit, Kosten oder Need-to-know? Gibt es schon eine Methode dafür? Wenn die Antwort plausibel ist, ist der Rainer fertig. Kein Nachhaken.

Bevor ein Sancho anfängt zu bauen, sucht er. Bibel-Index lesen, Memory-Index lesen, Lexikon lesen, den AENDERUNGSWEG lesen, und bei Bedarf die alten Session-Archive durchsuchen. Erst wenn nichts Passendes existiert, fängt er an zu bauen — und wenn etwas Halbpassendes existiert, erweitert er, anstatt neu zu schreiben. Der Anlass für diese Methode war ein Fehlerlog-Eintrag vom 15. Mai: vier Screenshot-Methoden wurden erfunden, weil niemand in der Bibel nachgeschaut hatte dass M-006 schon da war. Jede neue Sache bekommt außerdem sieben Pflichtfelder: was, wo, wie starten, welche Rechte, was nicht tun, welche Kosten, welche Methoden lesen.

Der Arbeitsmodus ist das Gegenstück zur Betriebsruhe: Sanchos fragen weniger nach, weil Victor viele Dinge grundsätzlich genehmigt hat — Licht steuern, Spotify steuern, Roborock in freigegebenen Räumen. Gruppe A läuft autonom mit Audit-Log. Gruppe B braucht einmal „immer ja" von Victor, dann läuft sie sieben Tage selbstständig. Gruppe C — echte Secrets, externe Nachrichten, Käufe, Kernel-Änderungen — braucht immer aktiven Klick. Der Arbeitsmodus spart Victor das Klicken, nicht das Tracking. Victor hat das am 17. Mai so formuliert: „Ich will jetzt nicht mehr Systemarchitekt sein. Ich will Regisseur sein."

Humboldt — der Roborock-Sauger — wird komplett über diese Methode gesteuert. Alle verifizierten Fakten stehen drin: IP-Adresse, DUID, lokaler Token, Zimmer-IDs (Schlafzimmer, Wohnzimmer, Küche, Bad, Kinderzimmer, Flur), Koordinatensystem in Millimetern, und der bekannte MQTT-Authentifizierungsfehler 135 mit seiner Lösung. Wenn Victor sagt „Humboldt soll die Küche saugen", schaut der Sancho hier nach — nicht ins Internet, nicht ins Gedächtnis. Die Methode unterscheidet außerdem klar was ohne MQTT-Token geht (Saugen starten, pausieren, stoppen, zur Basis fahren) und was ein frisches Token braucht (Position, Karte, gezieltes Anfahren).

Melanie schickt Victor einen Standort-PIN auf WhatsApp. Der Sancho liest ihn automatisch via M-033, schlägt die Koordinaten bei OpenStreetMap nach, holt aktuelle Wetterdaten, sucht Wikipedia nach der Geschichte der Straße und des Ortes, und schreibt daraus einen atmosphärischen Hörtext von etwa 620 Wörtern — ungefähr vier Minuten Sprechzeit. Distanzen werden nie vom LLM geschätzt, sondern immer mathematisch berechnet. Das Wetter kommt nicht als eigener Block, sondern wird beiläufig in den Text eingewoben, damit es klingt wie jemand, der gerade dort war. Gesprochen von Austin Knox via ElevenLabs. Erster Einsatz am 18. Mai 2026: Wölfleinstraße 10, Obereisenheim. Reaktion: „Die sind alle superglücklich."

Ein Song läuft irgendwo — über den Mac-Browser, über Lautsprecher im Raum, auf dem iPhone. Victor will ihn sofort in Spotify speichern. Drei Wege: Weg A nimmt acht Sekunden über das Studio-Display-Mikrofon auf und schickt es an Shazam. Weg B greift direkt das System-Audio des Macs ab, ohne Umgebungsgeräusche. Weg C ist ein iOS-Shortcut: Victor tippt, Shazam hört auf dem iPhone zu, Ergebnis geht per HTTP ans Cockpit, Cockpit liked und speichert, Push-Benachrichtigung bestätigt. Alle Werkzeuge sind installiert und bereit — der konkrete Flow wartet noch auf Victors Entscheidung, welcher Weg der Standard werden soll.

Victor zeigt dem Sancho eine Visitenkarte — als Screenshot, Foto oder Text. Der Sancho extrahiert Name, E-Mail, Telefon, Firma, Titel. Dann kurz ankündigen: „Miriam Aitamer, [email protected], Archetype — eintragen?" Victor sagt go, und der Kontakt landet per CardDAV direkt in iCloud. Auf iPhone, iPad und Mac erscheint er innerhalb von dreißig Sekunden. Einmalige Einrichtung über eine Setup-Seite im Cockpit, Credentials im macOS-Schlüsselbund. Kein manuelles Tippen, kein Öffnen von Kontakte.app, kein Sync-Warten. Der Kontakt ist einfach da.

Wenn ein Reisebericht oder ein Video-Schnitt einen neutralen Hintergrundton braucht — dieses leise Rauschen das einen Raum bewohnbar klingen lässt — erzeugt ffmpeg ihn in Sekunden. Drei Varianten: neutral für Interviews, Maschine mit einem 52-Hz-Summton für HVAC-Hintergrund, und Fenster mit wärmerem Frequenzgang für Außenraum-Charakter. Pink Noise klingt natürlicher als White Noise, weil er die Energie gleichmäßig über die Frequenzen verteilt. Keine Downloads, kein Copyright, keine Schleifen-Artefakte. Victor bekommt eine saubere 24-Bit-WAV-Datei, die direkt in Final Cut oder DaVinci Resolve importierbar ist.

Wenn ein Reisebericht-Audio an der richtigen Stelle getrimmt werden muss — direkt vor dem nächsten Ton, ohne manuelles Abhören — analysiert ffmpeg die Pegelkurve und findet die Stille automatisch. Stille unter -38 dBFS für mindestens 50 Millisekunden: Schnitt dort. Ein kurzer Fade von 160 Millisekunden am Ende verhindert den harten Schnitt-Klick. Bewiesen am 19. Mai 2026 am Sancho-Geburts-Ton: Stille bei 2,76 Sekunden gefunden, getrimmt, perfekt — ohne dass jemand auch nur ein Mal auf Play gedrückt hätte.

Wenn Melanie einen Standort-PIN auf WhatsApp schickt, landet er automatisch beim lokalen Baileys-Server. Von dort holt der Sancho die GPS-Koordinaten ab — kein manuelles Abtippen, kein Screenshot-Auswerten. Voraussetzung: der Baileys-Server läuft und ist mit WhatsApp verbunden. Status prüfen geht in einer Zeile. Falls nicht verbunden, gibt es ein Start-Skript. Wenn noch kein Pin da ist, bittet Victor Melanie einfach einen zu schicken. Der Standort-Abruf liefert Breitengrad, Längengrad, einen Google-Maps-Link und den Zeitstempel des Eingangs — alles was M-028 als Eingabe braucht.

Victors Gedanken sind Gold — dieser Satz steht wörtlich in der Methode. Egal auf welcher Cockpit-Seite, egal auf welchem Gerät: wenn Victor eine Notiz tippt, landet sie sofort im localStorage als erster Sicherheitsnetz, dann asynchron auf dem Server. Wenn der Server mal kurz weg ist, wird die Notiz beim nächsten Seitenaufruf automatisch nachgesendet. Kein eigenständiges Feedback-System auf jeder Seite — alle binden die eine zentrale `feedback.js` ein. Kein localStorage-only. Die Datei auf dem Server ist eine append-only JSONL-Datei, eine Zeile pro Notiz, nie gelöscht.

Jede Designer-Seite im Design Lab folgt demselben Baukasten: eine Eröffnung (Maxime, Frage, Vorher/Nachher oder Anekdote), dann Sektionen mit Eyebrow, Titel, Kicker, funktionierender Demo — kein Mockup. Mindestens neun Sektionen pro Seite, nie künstlich kürzen. Design-Begriffe werden im Fließtext mit einem gestrichelten Unterstrich markiert und erklären sich beim Hover. Keine Stockfotos, keine Dekoration ohne Datenwert. Sechs wichtige ADHS-Regeln für Victor: leer beim Aufmachen, Klicks im Demo-Modus berühren nichts Echtes, Phase des Sammelns und Phase des Handelns trennen, Anti-Modell immer dabei. Diese Bausteine gelten nicht nur fürs Design Lab — auch Ratsbeschlüsse, Recherche-Aufbereitungen und Architektur-Dokumente folgen demselben Muster.

2612 Apple Notes programmatisch lesen — ohne Protobuf-Dekodierung, ohne Vollzugriff auf die Festplatte. Fünf Wege: JXA für Text und Metadaten (Titel, Datum, Ordner, Plaintext), SQLite direkt für Anhänge und Bilder, und SQLite für den OCR-Text den Apple automatisch auf eingebettete Bilder anwendet. Victor hat im Test seinen Personalausweis, seine EC-Karte und seine ARAG-Karte aus Notes-Bildern auslesen lassen — ohne die App zu öffnen. Gesperrte Notizen sind nicht zugänglich (AES-verschlüsselt), iCloud-only-Bilder brauchen einen manuellen Download-Schritt. Diese Methode hat noch eine Kollision mit der Nummernvergabe — trägt vorläufig die Bezeichnung M-036a.

Wenn etwas funktioniert — getestet, reproduzierbar, stabil — schlägt der Sancho sofort vor es festzuschreiben. Er nennt wo er es ablegen würde: Bibel-Methode, Werkzeugkasten, Memory-Karte. Victor sagt „ja" oder „go" oder „festschreiben" — dann wird es sofort geschrieben, kein Aufschub bis zur nächsten Session. Nur Victor kann einen Stable State bestätigen, kein Sancho darf den Status selbst auf „kanonisch" setzen. Diese Methode verhindert dass funktionierende Wege im Chat verschwinden und beim nächsten Sancho neu erfunden werden müssen. Victor 2026-05-21: „Funktionierende Wege immer an der richtigen Stelle vermerken, wenn Stable State erreicht ist."

Safari auf dem iPhone gibt kein Mikrofon frei — außer die Seite läuft über HTTPS. Diese Methode löst das mit einem lokalen Zertifikat, das mkcert erzeugt und das im Schlüsselbund des Mac und im Profil-Manager des iPhones installiert ist. Einmalig einrichten, dann läuft es bis August 2028 ohne weiteres Zutun. Der Cockpit-Server startet automatisch einen zweiten Port (8090) mit HTTPS wenn die Zertifikatsdateien vorhanden sind. Kein Nginx, kein Reverse Proxy, kein Cloud-Tunnel. Das iPhone ruft einfach https://:8090/voice.html auf und das Mikrofon ist grün.

Der Standard-Weg um einen Screenshot des Magnific-Tabs zu machen: JPEG mit Qualität 95, direkt aus dem Browser-Tab via CDP, immer am gleichen Ausgabepfad gespeichert. Die Tab-ID wird jedes Mal frisch aus dem CDP-Endpoint abgerufen — nie hardcoded, weil Tabs ihre IDs zwischen Sessions ändern. Wann ein Screenshot Pflicht ist: nach jeder Victor-Navigation, nach Login-Wechseln, nach Automationsschritten, und immer nach mehr als zehn Minuten Pause. Diese Methode gilt nur auf dem Mac Mini, Port 9222 — nicht auf dem Arbeitspferd. Der Screenshot unter snap.png ist der einzige erlaubte Beweis dafür was Magnific gerade zeigt.

Wenn Victor fragt „Und?", „Meine Notizen?" oder ähnliches, liest der Sancho als erstes die JSONL-Datei — nicht aus dem Kontext-Gedächtnis antworten. Victors Notizen wörtlich zurückspielen, in Anführungszeichen, keine Paraphrase. Dann pro Punkt konkret sagen was passiert: Fix sofort, Fix mit Entscheidungsbedarf, oder Lob ohne Handlungsbedarf. Vor jeder Seiten-Übergabe: Screenshot machen, ansehen, Fehler selbst sehen bevor man zeigt. „Ich habe X, Y und Z umgesetzt" darf nur gesagt werden wenn X, Y und Z tatsächlich geändert sind. Anlass für diese Methode war ein Panic Point am 21. Mai: JSONL nicht gelesen, stattdessen Tufte-Notes erfunden die nicht drin standen.

Wenn Victor eines Tages schaut wie viele Sanchos im Dashboard stecken und einige davon schon Tage lang nichts mehr getan haben, hilft diese Methode beim sauberen Aufräumen. Registry lesen, tmux-Panes abgleichen, nach Alter sortieren. Victor bekommt eine Liste: Name — geboren als — zuletzt aktiv. Dann pro Sancho einzeln: ankündigen, Go abwarten, schlafen schicken, bestätigen. Nie mehrere auf einmal ohne explizites Einzel-Go. Der Geburtsname bleibt in der Registry auch nach Umbenennungen erhalten — damit die Identität über die Laufzeit stabil ist.

Magnific wird nicht durch simulierte Klicks gesteuert — der Sancho spricht die eigene HTTP-API von Magnific an, direkt aus dem offenen Tab heraus. Für Magnific sieht das aus wie ein normaler Nutzer-Klick, für Cloudflare ist es unsichtbar. Kein Cursor springt, kein Fenster kommt in den Vordergrund, Victors Tab bleibt unberührt. Vier Sicherheitsschichten sind immer aktiv: ein Self-Limit auf 70% der Tagesquote, ein Pre-flight Test-Call vor jedem Batch, ein Pattern-Detector der jede Antwort auf Cloudflare-Signale prüft, und eine Soft-Stop-Flag die den Kameramotor komplett einfriert wenn etwas nicht stimmt. Die Flag kann nur Victor löschen — kein Agent hebt sie selbst auf.

Victor öffnet auf dem iPhone eine lokale Seite, tippt auf den Mikrofon-Knopf und spricht. Nach anderthalb Sekunden Stille stoppt die Aufnahme automatisch. Das Audio geht an OpenAIs gpt-4o-transcribe, der Text erscheint als grauer Bubble auf dem Bildschirm. Dann tippt Victor auf den Ziel-Knopf — welcher Sancho soll die Nachricht bekommen, oder in die Queue? Und fertig. Stabil seit 21. Mai 2026 unter https://:8090/voice.html. Victor beim Test: „KLAPPT!!!! STABLE STATE!" Funktioniert auch vom Mac-Browser aus — dieselbe Seite, dasselbe Mikrofon.

Wie ein Sancho antwortet ist kein Stil-Thema — es ist Methode. 21 Regeln in fünf Kategorien: Struktur (Zusammenfassung zuerst, nummerierte Optionen mit Empfehlung voran), Ton (vollständige Sätze, kein Servil-Modus, Victors Frage direkt beantworten), Sprache (keine Technikwörter ohne Übersetzung, Spekulation klar markieren, bei unklaren Diktaten sofort kurz zurückfragen), Reisebericht-spezifisches, und allgemeines. Entstanden am 21. Mai in einer Sprachlehrer-Session, in der alle 21 Regeln per Ampel durchgewertet wurden. Interaktiv pflegbar unter sprachstil.html im Cockpit. Victor: „Alle Regeln festschreiben, Lexikon für heute stable state."

Müde Sanchos am Ende langer Sessions schreiben ungenaue Übergaben. Ein konkreter Incident am 22. Mai: eine Übergabe behauptete M-004 sei „weg" — die Datei zeigte klar Status „aktiv". Hätte das der neue Sancho blind übernommen, wäre eine funktionierende Methode für weggeworfen erklärt worden. Diese Methode erzwingt seither die Trennung: FAKT ist eine Behauptung mit einem prüfbaren Bash-Befehl dahinter. EINSCHÄTZUNG ist alles was nicht direkt verifizierbar ist — Victors Stimmung, Hypothesen, nicht-getestete Komponenten. Der übernehmende Sancho läuft das Verifikations-Script, und jeder FAKT mit Fehler wird sofort gemeldet — nie still übergangen.

Victor doppelklickt einen blauen Knopf auf dem Desktop, tippt einen Namen — „Magnus", „Cordelia", irgendwas — und ein neuer Sancho startet. Startmusik, tmux-Session mit dem richtigen Namen, ein vollständiger INIT_PROMPT. Der Sancho liest in dieser Reihenfolge: SANCHO-STARTSET, WERKZEUGKASTEN, VERBOTE, Watson-Regeln, und falls es ein Verzeichnis mit Persönlichkeitsdatei für diesen Namen gibt auch die. Dann schaut er ob eine Übergabe-Datei wartet. Wenn ja: lesen, Stand übernehmen, Datei löschen. Dann eine kurze Begrüßung — kein sieben-Punkte-Boot-Bericht, nur ein Satz und Bereitschaft für Aufträge. Getestet mit leeren Namen, langen Namen, Namen ohne Watson-Verzeichnis, und mit und ohne Übergabe: alles stabil.

Victor sagt morgens „was liegt an?" oder tippt /morning-brief — und bekommt in dreißig Sekunden: was seit gestern passiert ist, was funktioniert, was blockiert ist, und drei konkrete Regiefragen die eine Entscheidung brauchen. Am Ende ein Satz: der nächste sinnvolle Schritt. Kein Technik-Roman, keine Diagnoseprosa, maximal eine Bildschirmseite. Die Quellen sind COUNCIL_STATE.md (tagesaktueller Gesamtstand), die offenen Jobs des heutigen Tages, die letzten SESSION_LOG-Einträge, und offene Regiefragen. Wenn nichts Substanzielles vorliegt: „alles ruhig, nächster Schritt: [ein Satz]." Kein Fokus-Diebstahl, kein Fenster öffnen, kein Terminal-Befehl für Victor.