2026 Arbeitstagebuch

Die letzten Tage waren recht kompakt, daher habe ich nichts notiert. Doch ganz aufzuhören mit dem Notieren geht nicht, also nehme ich es jetzt wieder auf und halte alles auf einmal fest.

Abgesehen von der vielen Arbeit – warum habe ich nicht geschrieben?

1. Weil ich Angst davor hatte, dass ich mich zum Aufzeichnen eines Tages mindestens 30 Minuten lang hinsetzen müsste. Das ist eigentlich eine innere Belastung und Scheu vor dem täglichen Festhalten, die nicht gut ist.
2. Normalerweise möchte ich erst dann mit dem Schreiben beginnen, wenn der Tag wirklich vorbei ist. Aber wenn ich genauer darüber nachdenke, ist das irgendwie unnatürlich, denn ich krieche meistens sofort ins Bett, sobald es Schlafenszeit ist, und warte nicht darauf, dass ich wirklich alles getan habe, was ich tun wollte (gibt es das überhaupt?). Dadurch entsteht die Situation, dass ich in freien Momenten nicht aufzeichne, aber wenn es eigentlich an der Zeit wäre, muss ich schnell ins Bett. Und dann kommt noch Punkt 1 hinzu.

Die beiden Dinge zusammen führen dazu, dass sich immer mehr aufstaut.

1. Was habe ich heute gemacht:

   Genauer gesagt: Was habe ich in den letzten Tagen gemacht?

   1. Auf SCs Empfehlung hin habe ich begonnen, Neovim zu nutzen. Warum? Weil ich gesehen habe, dass nvim-orgmode mittlerweile tatsächlich ein brauchbarer Orgmode ist, und ich langsam von Emacs genervt bin:

      • Endlose Update-Fehler
      • Rätselhafte Debugging-Meldungen und Fehler
      • Überflüssige Flexibilität, die mir nur zusätzliche Last bringt
      • Ich verstehe Emacs-Lisp nicht und will es auch nicht verstehen.

      Jahrelang habe ich das alles ertragen, um Orgmode zu nutzen, aber es gab nirgendwo eine Alternative, die mir Orgmode in guter Qualität bot. Jetzt scheint es im Neovim-Lager eine Alternative zu geben – warum also nicht ausprobieren?

      Da ich selbst seit Jahren Vim-Benutzer bin und in Emacs auch evil-mode (vim-mode) verwendet habe, empfinde ich Vim nie als große Belastung. In VS Code und IntelliJ kann ich ohne Vim nicht überleben, daher ist die direkte Nutzung von Neovim für mich überhaupt kein Problem.

      Da die Hürde weg ist, habe ich mir das Neovim-Ökosystem angesehen. Mir gefällt, dass Neovim ohne den Ballast von Vimscript auskommt und Lua sowohl als Konfigurations- als auch als Plug-in-Sprache nutzt. Dadurch kann es leichtfüßig starten, und die Community ist sehr aktiv. Das Plugin-System von Neovim wird mittlerweile von einem System namens lazy.vim dominiert. Das Design von Plugins und Konfiguration in Neovim scheint gezielt und systematisch die alten Schwachstellen von Vim zu beseitigen. In Vim und Emacs gab es unzählige ähnliche Versuche, die allein durch die fragmentierte Community nie wirklich erfolgreich wurden.

      Also habe ich LazyVim direkt ausprobiert. Und siehe da – ich fühle mich, als hätte ich plötzlich ein VS Code, das im Terminal läuft. Weißt du, wie großartig das ist?

      Jetzt habe ich eine mächtige „Alte Gottheit“ auf einer völlig neuen Basis, die sich extrem einfach konfigurieren lässt – Flexibilität und Benutzerfreundlichkeit sind perfekt ausbalanciert. Meine alten Schmerzpunkte sind praktisch alle gelöst.

      Ich habe kaum Zeit gebraucht, um schon einen großen Teil meiner Arbeitsabläufe hierhin zu verlegen. Ich öffne jetzt in tmux fünf Fenster, in jedem Fenster starte ich Neovim in einem Ordner: links das Verzeichnis, in der Mitte der Code, rechts opencode und das Terminal.

   2. Eine Version von Legion aktualisiert. Ich habe den Textumfang des Legionmind-Skills deutlich reduziert (4.000 Zeilen weniger). Bisher scheint es, dass ich weniger eingreifen muss. Aber ich weiß nicht, ob es daran liegt, dass ich in letzter Zeit eher intelligente Modelle verwende, oder ob diese Version von Legionmind tatsächlich schlauer geworden ist.

   3. Einen OpenClaw aufgesetzt. Minimax 2.1 ist immer noch etwas dumm, aber als persönlicher Assistent finde ich OpenClaw ziemlich gut, weil es im Prinzip ein ChatGPT mit Gedächtnis plus Händen und Füßen ist (es kann meinen Computer bedienen).

   4. Für Yuan eine HTTP-Proxy-Funktion hinzugefügt und Metriken usw. ergänzt.

2. Was mir durch den Kopf geht

   Manchmal habe ich das Gefühl, dass das Schreiben mit KI ähnlich ist wie das Debuggen von Code, den man nicht vollständig versteht: Man testet ständig sein Verhalten oder gibt Logs aus, um beim Debuggen zu helfen. Man ändert hier etwas, fügt dort etwas hinzu, bis man schließlich ein zufriedenstellendes Ergebnis erhält. Ich versuche, den Ursprung dieses Gefühls zu ergründen:

   Beim Schreiben von Code mit KI gibt der Mensch einen Prompt ein, der konkrete Anweisungen enthält, und hofft, dass die KI die impliziten Anweisungen und Informationen hinter diesen Anweisungen versteht und die Aufgabe korrekt erledigt.

   Die Anweisungen, die man der KI mitteilen möchte, lassen sich in Ebenen unterteilen: Die oberste Ebene ist die Anweisung für die aktuelle Aufgabe. Darunter liegen die technischen Entscheidungen, die im Softwareprojekt getroffen wurden, sowie die bewährten Praktiken, die für diesen speziellen Teil des Projekts gelten. Die nächste Ebene sind die Hintergrundinformationen zum Problembereich, den das Projekt lösen soll. Darunter kommt das fachspezifische Wissen des Softwareentwicklers, der die KI benutzt – seine persönlichen Vorlieben, technischen Präferenzen, stilistischen Neigungen, seine historische Erfahrung und seine Denkweise. Die unterste Ebene sind die allgemeinen Weltkenntnisse.

   In einer Konversation mit der KI kann man ihr tatsächlich nur die Anweisungen für die aktuelle Aufgabe klar mitteilen und dann hoffen, dass die KI genügend Weltwissen und das nötige Hintergrundwissen zur Problemlösung besitzt.

   Daraus lässt sich ableiten: Wenn der Kontext einer Aufgabe klein genug ist, die Anweisungen glasklar sind und es keinen historischen Ballast gibt, sollte die KI problemlos in der Lage sein, die Aufgabe qualitativ hochwertig zu erledigen. Gibt es dagegen viele implizite Hintergrundinformationen, neigt die KI zu seltsamen Ergebnissen.

   Legionmind soll genau das erreichen: Der KI helfen, selbstständig Hintergrundwissen und bewährte Praktiken über das Projekt und den Problembereich zu sammeln. Das erfordert entweder gute logische Denkfähigkeiten und ein gutes Gedächtnis (Kontextkapazität) der KI, oder die KI muss über ausreichendes Weltwissen verfügen. Was über diese beiden Faktoren hinausgeht, kann man nicht retten.

   —

   Und dann finde ich, dass ich Neovim viel zu spät entdeckt habe.

3. Was ich morgen tun möchte

   Morgen besuche ich SC in seiner neuen Wohnung, wir spielen Brettspiele und zeigen SY nebenbei die Skiausrüstung.

Zl kam, es gab viele Informationen, ich muss sie verdauen. Wir haben ein Brettspiel gespielt, den Tragödienzyklus, und wir haben drei Stunden damit verbracht, die Regeln zu verstehen. Endlich, im letzten Szenario, als ich den Bösewicht-Dramatiker gespielt habe, habe ich den Reiz des Spiels gespürt, und das Spiel endete mit meinem vollständigen Sieg.

Heute war ein Tag der Zurückhaltung. Mir ist aufgefallen, dass ich ab meinem 25. Lebensjahr im Umgang mit Emotionen einen deutlichen Fortschritt gemacht habe: Neben den Emotionen ist immer ein Funken Vernunft als Copilot dabei. Dieser Funken Vernunft fungiert wie ein Regelstab inmitten der gewaltigen Reaktorkammer der Emotionen. Ohne diesen Stab würden die Emotionen außer Kontrolle geraten, eine sich selbst verstärkende Kettenreaktion auslösen und möglicherweise unzählige irreparable Folgen haben. Mit diesem Stab beginne ich zu verstehen, was gesagt werden kann und was nicht, was getan werden kann und was nicht, welche Entscheidungen getroffen werden können und welche nicht. Es ist eine erfreuliche Veränderung, die an mir geschieht.

1. Was heute gemacht wurde:

   1. Heute habe ich mit Legion das Design und die Implementierung des HTTP-Proxy für Yuan durchgeführt. Ich fand die Nutzung ziemlich geschmeidig. Unterwegs habe ich das Design überprüft und einen Punkt (wie ein verfügbares Terminal ausgewählt wird) geändert, dann dem Agent freie Hand gelassen – das Ergebnis war recht gut.
   2. Ich habe auch mit Legion eine automatische Aktualisierung von Midas durchgeführt. Allerdings hat die KI dabei durchweg schlecht abgeschnitten: Sie hat meine Anforderungen nicht richtig verstanden und die Verwendung von @yuants/protocol nicht richtig erfasst. Ich habe mehrere Verdachtsrichtungen: Die KI ist nicht intelligent genug (Deepseek wirkt vielleicht noch nicht besonders klug); die Überprüfung war nicht streng genug; oder die Wissensbasis ist nicht ausreichend präzise.
   3. Verdammt, letzte Nacht wurde ich durch einen Alarm geweckt. Der Host ist plötzlich ausgefallen, anscheinend gab es eine CPU-Spitze, die den Host in einen Zustand versetzt hat, aus dem er sich nicht selbst erholen konnte. Das Log des Hosts ist ein Haufen Mist. Mein Urteil: Der Alarm ist nützlich, das Log ist totaler Schrott. Notiert!

2. Was mir durch den Kopf geht:

   1. Unter der Dusche habe ich über die kritischsten Punkte meiner aktuellen Zusammenarbeit mit der KI nachgedacht. Erstens die Service-Verfügbarkeit des KI-Agenten selbst – er sollte nicht einfach mitten im Betrieb aussteigen. Nebenbei bemerkt, die Ralph-Schleife erhöht die Verfügbarkeit im Grunde nur durch ständiges, grobes Wiederholen. Zweitens: Wie nehme ich die Outputs der KI an? Wenn selbst ein Untergebener seinem Vorgesetzten gegenüber eine PowerPoint oder zumindest einen fachkundigen Mittler (den „teuren Sprachrohr“) braucht, wie kann sich der Report der KI dann nur auf flaches Markdown und Code beschränken? Könnte nicht jeder Punkt im KI-Report mit einem Artifact verlinkt sein? Könnte es nicht einen speziellen Citation Agent für diesen Teil geben?

      Allerdings ist meine aktuelle Nutzung der KI recht eingeschränkt – sie konzentriert sich nur auf Codierungsaufgaben.

   2. Ich denke genauer darüber nach, warum mein Multi-Agenten-System, obwohl ich es schon habe, stetig in den Graben abdriftet. Meine früheren Vermutungen weisen auf drei mögliche Ursachen hin:

      1. Die intellektuelle Fähigkeit der KI selbst
      2. Die menschliche Überprüfung war nicht streng genug
      3. Die Wissensbasis ist nicht detailliert genug, um der KI die richtigen Informationen für einen schnellen Start zu liefern

      Betrachten wir diese Punkte genauer. Punkt 1 bedarf keiner weiteren Überlegung. Die Arbeit an Richtung 2 kann sich tatsächlich auf ein immer detaillierteres RFC-Dokument stützen, um den nachfolgenden Schritten eine hinreichend korrekte Richtung zu geben. Aber diese Entwicklungsweise erinnert an das Wasserfallmodell, das Arbeiten durch einen linearen Prozess:

      Anforderungsanalyse -> Backend-Design -> Backend-Entwicklung -> Frontend-Entwicklung -> Integrationstests
      

      Die Ursachen dafür liegen auf zwei Ebenen: der technischen und der organisatorisch-prozessualen Ebene. Die organisatorisch-prozessuale Ebene ist der Hauptfaktor.

      Technisch gesehen bestehen natürliche Abhängigkeiten zwischen den Aufgaben: Das Frontend muss auf die Schnittstellen des Backends warten, das Backend wiederum auf die fertigen CRDs des Produkts. Als menschliche Organisation hat das Wasserfallmodell Probleme wie geringe Effizienz, schwer aufdeckbare Qualitätsrisiken, mangelnde Flexibilität und Teamkonflikte. In meiner Zusammenarbeit mit der KI existieren Effizienz und Teamkonflikte in der KI-Welt von Natur aus nicht. Es ist, als ob ich und die KI in unterschiedlichen Zeitdimensionen leben – mein Tag ist für die KI wie ein Jahr. Nun ja, geringe Effizienz könnte ein paar zusätzliche Tokens kosten, aber das ist nicht mein vordringlichstes Problem. Das eigentliche Problem, dem ich gegenüberstehe, sind Qualitätsrisiken durch Missverständnisse der Anforderungen oder Fakten sowie mangelnde Flexibilität.

      Ich muss einen Weg finden, die Fähigkeiten der KI maximal zu nutzen und gleichzeitig mich selbst maximal zu entlasten. Gemäß der Erfahrung menschlicher Organisationen muss ich ein Knoten in der Befehlshierarchie werden, der höher angesiedelt ist, der der KI Aufgaben anvertrauen kann, ohne dass sie vom Kurs abkommt.

      Die beiden entscheidenden Punkte sind:

      1. Ausrichtungsabgleich (Alignment of Intent)
      2. Schichtenweise Validierung

      Das muss ich noch tiefer durchdenken. Ich habe das Gefühl, ich sollte es mehr nutzen und auf mich wirken lassen.

   3. Ich muss mich vor der negativen Seite hüten, in einen Zustand zu verfallen, in dem ich nur nach Nägeln suche, weil ich einen Hammer habe: Pfadabhängigkeit, Output statt Verständnis.

3. Was ist für morgen geplant?

   Morgen kommt ZL. Geplant sind Sport, Essen gehen und ein bisschen Gesellschaftsspiele.

Heute bin ich zum Friseur gegangen. Als ich zurückkam, stellte ich fest, dass das System instabil war. Letztendlich lag es daran, dass Jige zwei Terminals_id mit demselben Dienst gestartet hatte, die sich gegenseitig übernommen haben, was zu einem großen Problem führte.

1. Was ich heute gemacht habe:

   1. Ich habe versucht, den Cluster hinter eine NAT zu migrieren, natürlich mit der brandneuen Legion. Mein Vorgehen war:

      • Zunächst änderte ich den kops‑Cluster, erstellte ein neues VPC mit den Subnetzen 172.21.0.0/24 und 172.21.1.0/24. Dann erstellte ich eine NAT für den ausgehenden Datenverkehr.

        Eigentlich hatte ich einen Bereich mit 10.0 vorne geplant, aber nach einem Versuch stellte ich fest, dass AWS diesen CIDR nicht erlaubt, also änderte ich ihn auf 172.21. Dabei gab es eine Falle: In der Cluster‑Ressource muss der vorhandene Loadbalancer auf das entsprechende VPC verweisen (normalerweise implizit standardmäßig zugewiesen, jetzt muss man wegen des zusätzlichen CIDR manuell angeben).

      • Dann erstellte ich eine neue Instance Group, die auf das neue VPC zeigt. Es gab einen kleinen Zwischenfall: Die neue IG hatte keine S3‑Berechtigungen – aus irgendeinem Grund. Nach manuellem Hinzufügen traten die Knoten normal dem Cluster bei.

      • Der nächste Schritt war, die Dienste manuell in die neue IG zu migrieren.

      • Schließlich entfernte ich die ursprüngliche IG.

      Als alles erledigt war, stellte ich fest, dass der gesamte ausgehende Verkehr des Clusters nur eine einzige IP hatte, was unseren IP‑ratenbegrenzten Dienst ziemlich überforderte. Ich musste das Rollback durchführen und zuerst die HTTP‑Proxy‑Fähigkeiten entwickeln, bevor ich weitermachen konnte.

   2. Multi‑Agent wurde verwendet, um ein Skript zur automatischen Aktualisierung des Midas‑Nettowerts zu praktizieren. DeepSeek hat lange daran gearbeitet, und ich bin recht zufrieden. Das Kernproblem dabei ist: Wenn ich früh im Entwurf einen Fehler übersehe, erwartet mich eine enorme Verschwendung von Token und Zeit, da ich festgestellt habe, dass die Agenten nicht besonders schnell arbeiten.

      Derzeit sind diese Coding‑Agenten noch recht primitiv. Sie stürzen oft aufgrund von Netzwerkproblemen ab. Es ist noch etwas schwierig, sie für ernsthafte langlaufende Arbeiten einzusetzen – der SLI ist noch nicht gut genug. Das könnte auch eine Chance sein, aber es erfordert Kenntnisse in Softwareentwicklung und Hochverfügbarkeit, um zu funktionieren.

2. Was ich denke:

   Heute hatte ich nicht viele Gedanken; sie sind alle inline in den obigen Abschnitten geschrieben.

3. Was ich morgen vorhabe:

   1. Das HTTP‑Proxy‑Mechanismus von Yuan entwerfen.
   2. Nach dem Deployment den Cluster erneut migrieren.

Heute habe ich bis 11 Uhr durchgeschlafen, fühlte mich total entspannt – so ausgiebig geschlafen habe ich schon lange nicht mehr.

1. Was ich heute gemacht habe:

   1. Neue Version von node-unit deployed. Der Hauptgrund, warum ich relativ beruhigt deployen konnte, ist, dass ich umfassende End-to-End-Tests habe. Im Detail: Ich habe einen TimescaleDB (PostgreSQL 17) per Docker gestartet, dann zwei Instanzen von node-unit hochgefahren und 21 Einträge von @yuants/portal in die Datenbank eingefügt, um zu testen, dass die Verteilung am Ende auf 50/50 konvergiert.

      Dieser Test deckt im Wesentlichen ab, was passiert, wenn viele herrenlose Deployments auftauchen. Sobald zwei node-unit-Instanzen laufen, kann man beobachten, wie sie sich abwechselnd die Deployments schnappen. Was noch fehlt, ist einerseits die tatsächliche CPU-/Memory-Last durch Workloads und andererseits das Szenario, dass eine node-unit aus irgendeinem Grund offline geht.

   2. Mit der neuen Multi-Agent-Version von Legionmind in Yuan das Problem des Output-Streams des Earn-Kontos von vendor-gate gelöst. Ich habe den Agenten angewiesen, zunächst mit Legion Dokumentation zu erstellen. Insgesamt kamen folgende Dokumente dabei heraus:

      .legion/tasks/vendor-gate
      ├── context.md
      ├── docs
      │   ├── api-doc.md
      │   ├── pr-body.md
      │   ├── report-walkthrough.md
      │   ├── rfc.md
      │   ├── spec-bench.md
      │   ├── spec-dev.md
      │   ├── spec-obs.md
      │   └── spec-test.md
      ├── plan.md
      └── tasks.md
      

      Das fühlt sich nach einem vernünftigen Workflow an. Allerdings gibt es Konflikte zwischen meinem neuen Multi-Agent-System und der existierenden Dokumentationserstellung von Legionmind. Ich sollte die Grenzen der einzelnen Aufgaben sorgfältig überdenken. Die Spezifikationen für die Erstellung der einzelnen Dokumenttypen sollten in separate Skills ausgelagert werden, während Legionmind eher eine Workflow-Beschreibung sein sollte. Jeder Agent sollte einige kleinere Skills laden können, um seine Arbeit zu unterstützen.

      Ein weiteres Problem: Bei der ersten Ausführung hat der Agent einen Fehler gemacht und den Account-Output-Stream in account-actions-with-credential.ts ausgegeben. Der Grund: Ich hatte ihn angewiesen, sich an vendor-okx zu orientieren, um das Earn-Konto anzubinden – weil bisher nur das Earn-Konto von OKX als Account integriert ist. Allerdings hat die KI auch einige veraltete Praktiken übernommen. Der aktuelle Standard für Exchange-Integrationen ist, alle Konten über provideExchangeServices zu veröffentlichen, nicht über provideAccountActionsWithCredential.

      Dieses Wissen besitzt ein brandneuer KI-Agent nicht. Wie kann man dieses Wissen modellieren? Wie kann man dem KI-Agenten diesen Projektkontext als externes Gehirn bereitstellen? Das ist eine tiefgründige Frage, über die ich morgen nachdenken muss.

   3. Nachmittags habe ich gekocht, um die Freunde von SY zu bewirten – das hat mich ganz schön geschlaucht. Morgen geht es also mit der Arbeit weiter.

2. Gedanken:

   • Wie oben erwähnt, muss ich genau überlegen, wie ich dem KI-Agenten kompakt ein externes Gehirn designen kann. Der einfachste Ansatz wäre, mit einer Reihe von AGENT.md-Dateien zu beginnen. Das habe ich bereits versucht, aber der Overhead für die Pflege dieser Dokumente ist recht hoch. Es ist schwierig, zwischen nutzlosem Wissen und wirklich bewahrenswerten Erfahrungen zu unterscheiden. Derzeit scheint das Gedächtnis wie ein weiterer Prompt zu sein, nur dass der Agent zusätzlich eine Rückkopplungsschleife hat, um das Gedächtnis selbst zu aktualisieren. Am wichtigsten ist jedoch, wie man die Arbeitsergebnisse des KI-Agenten bewertet.

   • Zu diesem Punkt: Ich habe einen interessanten Artikel gelesen, den ich jetzt in meinen eigenen Worten zusammenfasse: Zunächst zur Bewertung der Einzelschritte eines Agenten. Diese Bewertung kann in verschiedene Kategorien unterteilt werden:

     1. Statische Tool-Evals: Compiler, Linter, Unit-Tests, E2E-Tests
     2. Model-Evals: Bewertung durch ein anderes LLM anhand selbstdefinierter Prompts
     3. Manuelle Evals: Bewertung durch mich persönlich

     Für eine systemische Bewertung eines Agenten gibt es zwei Arten:

     1. Fähigkeitsbezogen: Beantwortet die Frage „Was kann der Agent?“. Die Erfolgsquote kann niedrig sein – z.B. wenn ich Legion nutze, um schrittweise größere, schwierigere Aufgaben zu bearbeiten. Das fühlt sich an wie die Erkundung einer neuen Grenze.
     2. Regressionsbezogen: Kann der Agent noch die Fähigkeiten behalten, die er zuvor hatte? Z.B. wiederholtes Testen bestimmter Aufgaben, um sicherzustellen, dass sie stabil erledigt werden.

     Sobald eine neue Fähigkeit eingeführt wird, sollte man von der fähigkeitsbezogenen zur regressionsbezogenen Bewertung übergehen.

     Der Artikel erwähnt auch zwei wichtige Metriken: pass@K und pass^K

     • pass@k: Mindestens ein Erfolg in k Versuchen. Je mehr Versuche, desto höher die Wahrscheinlichkeit mindestens eines Erfolgs. Anwendbar, wenn man nur daran interessiert ist, „mindestens eine brauchbare Lösung zu finden“.
     • pass^k: Alle k Versuche müssen erfolgreich sein. Je mehr Versuche, desto schwieriger wird die Konsistenz. Anwendbar, wenn der Benutzer einen zuverlässigen Produktionsagenten erwartet.

     FYI: Siehe diesen Artikel

   • Meine Energie ist immer noch etwas schwach. Nachmittags ein bisschen gearbeitet, abends gekocht – fühlte mich schon etwas müde. Wann werde ich so wie CZ gar keinen Schlaf mehr brauchen?

3. Was ich morgen vorhabe:

   1. Über das Modell des Bewertungs-Agenten nachdenken und das Multi-Agent-System weiter iterieren.
   2. Clustersicherheit – das muss unbedingt angegangen werden.
   3. legion-github-bridge

Heute habe ich eine leichte Erkältung, Kopfschmerzen und eine geringe Produktivität, aber ich bin froh, dass ich angefangen habe, tägliche Zusammenfassungen zu machen.

1. Was ich heute gemacht habe:

   1. Mit Hilfe von KI ein Multi-Agent-System entworfen, das noch nicht systematisch verfeinert wurde.
   2. Der legionmind-github-bridge hat wieder einen Schritt nach vorne gemacht.
   3. Das Preemptive-Design und die Implementierung von node-unit überarbeitet: Zuvor wurden bei einem fehlgeschlagenen node-unit alle darunterliegenden Deployments gelöscht, jetzt werden sie einzeln bereinigt.
   4. An der Prüfung der China Financial Futures Exchange (CFFEX) für die Kontoeröffnung bei einem Futures-Broker teilgenommen. Es war erforderlich, die gesamte Prüfung über die Kamera zu laufen, ohne das Fenster zu minimieren oder zu wechseln. Glücklicherweise konnte man unbegrenzt oft probieren – das hat mich nicht aufgehalten, ich habe mit 95 Punkten bestanden.

2. Gedanken:

   Mein Ziel ist es, eine möglichst weitgehende Autonomie der Agenten bei minimalem Verschleiß zu erreichen. Derzeit sieht mein Arbeitsablauf so aus:

   1. legionmind dient als SOP für die Entwicklungsarbeit. Es ist eine Agent Skill – ich mag Agent Skills.
   2. opencode ist die konkrete Instanz des Agenten. Ich nutze daraus Fähigkeiten wie bash, tool calling, langraph, command, subagent usw. Falls ich opencode eines Tages aufgeben sollte, wäre dies meine Liste der zu implementierenden Punkte.
   3. Derzeit bereitet mir Kopfzerbrechen, wie ich die Skills mit diesen Sub-Agenten kombinieren soll.

   Nach einem Tag mit Kopfschmerzen wurde mir erst am Abend klar: Es ist vielleicht keine gute Idee, diese Gedanken am Ende des Tages niederzuschreiben. Vielleicht sollte ich nur Fakten festhalten und die Gedanken morgen früh nach dem Aufwachen zusammenfassen.

3. Was ich morgen vorhabe?

   1. Mit dem Multi-Agent-System etwas anfangen – z. B. das Gate-Anlagekonto anbinden.
   2. Weiter am legionmind-github-bridge arbeiten.
   3. Cluster-Sicherheit, falls Zeit bleibt.
   4. Wieder mit der Zeiterfassung für die Arbeit beginnen (wichtig).
   5. Morgen kommen SYS Freunde zu Besuch, daher wird die Arbeitszeit wahrscheinlich eingeschränkt sein.