feat(iris-rustapp-crafter): Plugin plant und baut Rust-Apps (panel-kit + Figcraft) mit Claude Code #388
Labels
No labels
herkunft/alpha-feedback
status
blockiert
status
zu-testen
typ
bug
typ
docs
typ
enhancement
typ
feature
typ
idea
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
iris/iris-plugins#388
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Warum
Komplexere Anwendungen werden bisher im Gespräch mit Iris geplant und Claude Code von Hand Aufgaben gegeben. Das Plugin führt diesen Weg als State Machine von der Idee bis zur fertigen Rust-App und lässt Iris Claude Code selbstständig Schritt für Schritt ansteuern, das Ergebnis beurteilen und den nächsten Schritt wählen (ähnlich Craft Anything, aber ohne Original).
Entscheidungen (grill-me, bestätigt)
iris-rustapp-crafter; benutztiris-plugin-devnicht, übernimmt dessen State-Machine-Prinzip als eigene Implementierung. Zielplattform zunächst Mac, Linux später (keine Mac-Pfade, kein fest verdrahtetes127.0.0.1).einrichten→idee→grill→beschreibung(Freigabe) →gui(Freigabe) →schritte(Freigabe) →ausfuehren→abnahme. Freigaben tragen Wortlaut und Zeitstempel. Planstufen laufen über ein eigenes Issue und einen PR (01-planung).main(nur der erste Commit direkt). Jede Änderung: Issue, BranchNN-slug, PR, Standkommentar. Das Skript merged per Rebase automatisch, sobald alle Tests grün sind; Issues bleiben offen und bekommenstatus/zu-testen, Schließen bleibt beim Nutzer.ship,new-project,pull-allwerden verallgemeinert ins Plugin übernommen (Forgejo-API, keinshipvorausgesetzt).claude -p,--resume), im Hintergrund mit Logdatei. Eigenesiris-claude-execim Plugin (ohne Abfrage von Iris). Provider bei der Installation: Claude-Konto, lokaler OpenAI-kompatibler Server (mit Anthropic→OpenAI-Proxy), eigene Basis-URL mit Schlüssel (Schlüssel nur in Datei mit Rechten 600, nie in Zustand/Protokoll/Issue).main, nichts veröffentlichen.cargo fmt --check,cargo clippy,cargo test --workspace(vom Skript); dazu je Schritt eine freigegebene Abnahme. Ein Schritt ohne Abnahme-Eintrag ist nicht freigebbar; ein Schritt, der Code ändert, aber keine Tests mitbringt, wird nicht gemerged.frontend/panel-kit(Leptos) auf. Entwurf in Figcraft: Datei im Repo (gui/), je Panelart ein Frame, Export (PNG, Layer-JSON, Tokens →--pk-*) mit Fingerabdruck. Übergabe-Prinzip: Iris entwirft, der Nutzer passt an, Iris liest den Stand. Hermes und Claude Code nutzen den Figcraft-MCP-Server (headlessfigcraft-cli mcp).pull-3rd-partylädt dieFigcraft.app(mitfigcraft-cli) in die Generic-Packages-Registry des eigenen Forgejo, später den Docker-Container für Linux. Das Plugin installiert sie im Konfigurationsbereich (Prüfsumme, Version, Aktualisieren) und trägt den MCP-Server in die Hermes-Config ein. Kein Docker auf dem Mac nötig.Nicht Teil
Offen
Figcraft.appauf einem frischen Mac ohne Warnung? (Test in frischer VM)panel-kit/demooderrust-iris-nx; Browser-only oder Tauri?pull-3rd-party; Übernahme des Anthropic→OpenAI-Proxys ins Plugin.PR #389 gemergt: docs(iris-rustapp-crafter): Plan für das Plugin (#388)
http://docker:3000/iris/iris-plugins/pulls/389
Commits:
Stand
Befund: Aus einer grill-me-Runde (2026-11-12) steht der Plan für
iris-rustapp-crafter: ein eigenständiges Plugin, das Rust-Apps auf Basis vonpanel-kitplant, in Figcraft entwirft und Claude Code Schritt für Schritt ansteuert.Geändert: Neu
iris-rustapp-crafter/PLAN.mdmit den elf Entscheidungen, der Stufentabelle (einrichtenbisabnahme), den offenen Fragen und „Lessons Learned". Kein Code, keinplugin.json.Geprüft: Aussagen über vorhandene Werkzeuge gegen den Quelltext gelesen (
tools/iris-claude-exec,iris-agent-common.shmit den Backends,pull-3rd-partymit der Paketmenge,panel-kit/CLAUDE.md,3rdparty/figcraft/docs/mcp.mdzu headlessfigcraft-cli mcp,iris-plugin-dev/PLAN.mdzur State Machine).Nicht geprüft: Ob die per Skript geladene, nicht notarisierte
Figcraft.appauf einem frischen Mac ohne Warnung startet; ob Figcraft-Container-Server und Web-Oberfläche gemeinsames Live-Bearbeiten tragen; Obfigcraft-cliim Bundle derpull-3rd-party-App tatsächlich liegt; nichts gebaut oder ausgeführt.Grenzen: Nur Mac; Linux später. Der Plan ist die Spezifikation, Änderungen daran laufen über dieses Issue.
Offen: Projektgerüst (
panel-kit/demooderrust-iris-nx; Browser-only oder Tauri), Sitzungsdauer von Claude Code, zwei Folge-Issues (Upload der Figcraft.app inpull-3rd-party, Proxy-Übernahme). Nächster Zug: Bauabschnitt 1 (Kern: Zustand, Stufentabelle, Fingerabdrücke) nach Alfs Okay.PR #390 gemergt: feat(iris-rustapp-crafter): Kern mit Zustand, Stufen und Fingerabdrücken (#388)
http://docker:3000/iris/iris-plugins/pulls/390
Commits:
Stand
Befund: Bauabschnitt 1 (Kern) von
iris-rustapp-crafterist gebaut: die State Machine als eigene Implementierung, ohneiris-plugin-devzu benutzen.Geändert:
skills/iris-rustapp-crafter/rc_kern.py(Zustand.crafter/state.json, Stufentabelleeinrichtenbisabnahmeals Daten, Fingerabdrücke je Bereich, Freigaben mit Wortlaut und Zeit, Belege, Markierungen,neu,status),rustapp_crafter.py(CLI, nur Standardbibliothek),tests/test_kern.py;PLAN.mdum die Bauabschnitte ergänzt. Jede Freigabe hat einen eigenen Befehl (grill-fertig,beschreibung-freigeben,gui-freigeben,schritte-freigeben,abnahme), einen allgemeinen „Freigabe setzen“ gibt es nicht.Geprüft: 31 Tests grün (
python3 -I -m unittest discover -s tests): keine überspringbare Stufe, Rückfall nur der betroffenen Stufe bei Änderung (Beschreibung, GUI-Export, Schritte, Grill-Protokoll, Löschen, Umbenennen), Code ändert keine Planfreigabe,target/,node_modules/, Symlinks und.DS_Storezählen nicht, Freigabe braucht Wortlaut und Dateien im Bereich, beschädigter oder fremder Zustand bleibt unverändert, keine absoluten Pfade im Zustand, negativer Beleg hält die Stufe an. Dazu ein Aufruf des Skripts perpython3 -Iaus einem anderen Verzeichnis.Nicht geprüft: Alles außerhalb des Kerns: Es gibt noch kein
plugin.json, keinen Skill, keinen Systemprompt, kein Panel;einrichtenundausfuehrensind als „noch nicht verfügbar“ gekennzeichnet. Nichts in der echten Iris oder gegen Forgejo ausprobiert.Grenzen: Der Fingerabdruck des Bereichs
codeumfasst alles außer Plan, GUI,.crafterund den ignorierten Ordnern. Ob das für große Projekte schnell genug bleibt, ist ungemessen.Offen: Bauabschnitte 2 bis 8 (Konfiguration, Forgejo-Teil, grill/Beschreibung/Schritte,
iris-claude-exec, Figcraft, Ausführungsschleife, Skill/Panel/Doku). Nächster Zug: Bauabschnitt 2 (Einstellungen und Konfiguration).PR #391 gemergt: docs(iris-rustapp-crafter): Übergabestand nach dem Kern (#388)
http://docker:3000/iris/iris-plugins/pulls/391
Commits:
Stand
Befund:
session-kontext.mdnannte nach #390 noch „nichts gebaut“.Geändert: Der Satz zu
iris-rustapp-crafternennt jetzt Bauabschnitt 1 als gebaut und Bauabschnitt 2 als nächsten Zug.Geprüft: Textstelle gelesen. Nicht geprüft: nichts weiter nötig (nur Text).
PR #392 gemergt: feat(iris-rustapp-crafter): Konfiguration für Forgejo und Provider (#388)
http://docker:3000/iris/iris-plugins/pulls/392
Commits:
Stand
Befund: Bauabschnitt 2 (Konfiguration) von
iris-rustapp-crafterist gebaut: Forgejo-Zugang und Provider/Modell für Claude Code, ohne Netzwerk und ohne Oberfläche.Geändert:
rc_konfig.py(Datei im Iris-Datenverzeichnis mit Rechten 600, atomar geschrieben; Forgejo-URL, Besitzer, Token; Providerclaude-konto,lokal,basis-urlmit Basis-URL, Modell, Schlüssel; Prüfung der Werte; Liste, was fehlt),panel_api.py(status,save,config-status), neuer Befehlkonfig status|setzenim Skript;rc_kern.pynennt die Befehle in der Stufeeinrichten;PLAN.mdundsession-kontext.mdnachgezogen. Geheimnisse gibt es nur über die UmgebungsvariablenRUSTAPP_CRAFTER_FORGEJO_TOKENundRUSTAPP_CRAFTER_API_KEYoder den Body des Panels, nie als Argument, und sie erscheinen nur als „gesetzt“.Geprüft: 61 Tests grün (31 Kern, 30 Konfiguration): Rechte 600 auch für das neu angelegte Verzeichnis, zu offene Datei wird auf 600 gesetzt, beschädigte Datei und fehlerhafte Änderung lassen die Datei unverändert, URL- und Namensprüfung (keine Zugangsdaten in der URL), Pflichtfelder je Provider, leeres Geheimnis lässt den Wert unverändert,
loeschen, keine Geheimnisse in Status, Fehlermeldungen und Panel-Antworten,panel_api.pyals echtes Skript mitpython3 -I. Gegenprobe: ein im Code eingebauter Token in der Ausgabe macht zwei Tests rot, danach zurückgesetzt und wieder grün.Nicht geprüft: Ob der Pfad des Iris-Datenverzeichnisses (
~/Library/Application Support/Iris, sonst~/.config/iris) in der echten Iris derselbe ist, den das Panel dort beschreibt; keine Verbindung zu Forgejo, kein Token auf Gültigkeit geprüft; die Figcraft-Einstellung fehlt; keine Oberfläche (web/settings.html), keine Abfrage per Canvas, keinplugin.json.Grenzen: Das Token liegt im Klartext in der Datei mit Rechten 600 (wie bei
iris-plugin-dev), nicht in der Keychain.Offen: Bauabschnitte 3 bis 8. Nächster Zug: Bauabschnitt 3 (Forgejo-Teil: Verbindungsprüfung,
einrichten, Ersatz fürship, automatischer Merge bei grünen Tests).PR #393 gemergt: feat(iris-rustapp-crafter): Forgejo-Verbindung und Einrichten des Repos (#388)
http://docker:3000/iris/iris-plugins/pulls/393
Commits:
Stand
Befund: Bauabschnitt 3a von
iris-rustapp-crafterist gebaut: Forgejo-Verbindung prüfen und das Repo des Projekts einrichten.Geändert:
rc_forgejo.py(Forgejo-Client,konfig pruefen,einrichten),rc_netz.py(IPv4 zuerst), Befehlekonfig pruefenundeinrichtenim Skript,tests/helfer.py(Fake-Forgejo mit echten Bare-Repos) undtests/test_einrichten.py;PLAN.mdundsession-kontext.mdnachgezogen.einrichtenlegt das Repo privat an, stellt „Rebase“ und „Branch nach Merge löschen“ ein, legt fehlende Labels an, initialisiert Git im Workspace, pusht den ersten Commit direkt aufmainund schütztmaindanach.Geprüft: 82 Tests grün (auch mit
-W error::ResourceWarning; dabei ein nicht geschlossener HTTPError gefunden und behoben): Organisation und eigenes Konto erkannt, fremdes Konto abgelehnt, ungültiges Token und unerreichbarer Server melden klar ohne das Token,konfig pruefenschreibt nichts, voller Ablauf mit allen Einstellungen, erster Commit vor dem Schutz, Zustand ohne URL, zweiter Aufruf ändert nichts, Token weder im Git-Remote noch im Zustand noch in Ausgaben, Abbruch beim Schutz und beim Einstellen wird ohne doppeltes Anlegen fortgesetzt, ein vorhandenesmainwird nie überschrieben, Labels der Organisation nicht doppelt.Nicht geprüft: Gegen einen echten Forgejo ist nichts gelaufen. Die Feldnamen der API für Branch-Schutz (
rule_name,enable_push,required_approvals) und Repo-Einstellungen (default_merge_style,default_delete_branch_after_merge) stammen aus meiner Kenntnis der API, der Fake prüft sie nicht gegen das echte Schema; ob Forgejomainnach dem Schutz tatsächlich Pushes ablehnt und PR-Merges zulässt, ist ungeprüft. Git über HTTP mithttp.extraHeaderist nur über lokale Bare-Repos getestet.Grenzen: Ein bereits vorhandenes Projekt auf einem anderen Rechner wieder aufnehmen (Klon holen) geht noch nicht über
einrichten.Offen: 3b (Ersatz für
ship), Bauabschnitte 4 bis 8. Vor 3b ein Echtlauf voneinrichtengegen ein Wegwerf-Repo auf dem eigenen Forgejo, wenn Alf zustimmt.PR #394 gemergt: feat(iris-rustapp-crafter): Senden als Ersatz für ship mit Prüfung und Merge (#388)
http://docker:3000/iris/iris-plugins/pulls/394
Commits:
Stand
Befund: Bauabschnitt 3b von
iris-rustapp-crafterist gebaut: der Ersatz fürship. Damit steht der Forgejo-Teil (Bauabschnitt 3) komplett.Geändert:
rc_senden.py(issue anlegen,senden),rc_pruefen.py(feste Rust-Prüfung, Testpflicht), Befehle im Skript, Fake-Forgejo um Issues, PRs, Kommentare, Labels, Merge und einen Hook erweitert, der Pushes aufmainnach dem Schutz ablehnt;tests/test_senden.py;PLAN.mdundsession-kontext.mdnachgezogen.sendenmacht ausmaineinen BranchN-slug, committet, pusht, legt den PR an (oder nimmt den vorhandenen), führtfmt,clippy -D warningsundtest --workspaceaus, schreibt den Standkommentar mit PR-Link, Commits und Prüfergebnissen ins Issue und merged per Rebase nur bei grüner Prüfung und mit Tests in der Änderung. Danachstatus/zu-testen, zurück aufmain, Branch gelöscht. Das Issue bleibt offen.Geprüft: 112 Tests grün (auch mit
-W error::ResourceWarning): Nachricht muss auf(#N)enden, Slug und Pflichtabschnitte des Standkommentars werden geprüft (jeder einzeln; „Nicht geprüft“ zählt nicht als „Geprüft“), unbekanntes oder geschlossenes Issue und „nichts zu senden“ werden abgelehnt, bei Eingabefehlern gibt es keine Schreibaufrufe und keinen Branch, Plananderung ohneCargo.tomlwird gemergt, nie direkt aufmain(der Push dorthin scheitert am Schutz), Issue bleibt offen, kein DELETE und kein Ändern von Issues, zweiter Aufruf auf demselben Branch nutzt denselben PR, rote Prüfung und Code ohne Tests werden nicht gemerged und im Kommentar genannt, fehlendescargoist rot statt Absturz, Token nirgends in Ausgabe, Kommentar oder Remote, Merge verweigert lässt den PR offen und das Label ungesetzt. Gegenprobe: ein im Code eingebauter Merge trotz roter Prüfung macht sechs Tests rot, danach zurückgesetzt und wieder grün.Nicht geprüft: Gegen einen echten Forgejo ist nichts gelaufen, weder
einrichtennochsenden: Feldnamen und Verhalten der API (Branch-Schutz,Do: rebase, Labels per ID, ob der Schutz PR-Merges durch das Token zulässt) stammen aus meiner Kenntnis, der Fake prüft sie nicht gegen das echte Schema. Die Prüfung lief nur mit eingespeistem Ausführer, nie mit einem echtencargo. Der Fake merged per Fast-Forward, nicht per echtem Rebase.Grenzen: Ein reines Refactoring ohne neuen Test wird nicht gemerged (Testpflicht ohne Ausnahme). Die Abnahme je Schritt aus der Schrittliste fehlt bis Abschnitt 4. Ein vorhandenes Projekt auf einem anderen Rechner wieder aufnehmen geht noch nicht.
Offen: Echtlauf gegen ein Wegwerf-Repo auf dem eigenen Forgejo (nur mit Alfs Okay); Bauabschnitte 4 bis 8.
PR #395 gemergt: fix(iris-rustapp-crafter): PR-Nummer wird nicht als Issue akzeptiert, Echtlauf dokumentiert (#388)
http://docker:3000/iris/iris-plugins/pulls/395
Commits:
Stand
Befund: Echtlauf von
einrichtenundsenden(Bauabschnitt 3) gegen den eigenen Forgejo, mit einem Wegwerf-Repoiris/crafter-echtlauf-test, das danach gelöscht wurde (DELETE 204, danach 404). Der Forgejo-Teil funktioniert wie im Fake, mit einer gefundenen Lücke.Geändert:
rc_senden.pylehnt eine PR-Nummer als Issue ab (Forgejo nummeriert Issues und PRs gemeinsam und liefert PRs über die Issue-Route); der Fake intests/helfer.pybildet das nach, ein neuer Test deckt es ab (113 Tests);PLAN.mdmit dem Ergebnis des Echtlaufs, einer Lektion undsession-kontext.mdnachgezogen.Geprüft (alles gegen den echten Forgejo, mit eigener Konfigurationsdatei im Scratchpad):
konfig pruefen(Token gültig, Besitzer ist Organisation);einrichten: Repo privat, Merge-Stil Rebase, Merge-Commits und Squash aus, Branch nach Merge löschen,maingeschützt (kein Push, 0 Reviews), per API nachgelesen: die Feldnamen stimmen; ein direkter Push aufmainwird abgelehnt („pre-receive hook declined“); Konfigurationsdatei mit Rechten 600, Token weder im Git-Remote noch im Zustand. Wiederaufnahme:einrichtennach einem (von mir selbst verursachten) Verlust der Markierung lief ohne zweites Repo und ohne zweiten Commit durch.issue anlegenmit Label per ID.sendenmit Planänderung: gemergt per Rebase, Issue offen mitstatus/zu-testenundtyp/feature, Standkommentar mit PR-Link, Commits und Prüfzeile, Branch gelöscht, Workspace zurück aufmain.sendenmit echtemcargo: falsch formatiert →fmtrot,clippyundtestgrün, PR offen, kein Label; nachcargo fmtauf demselben Branch → derselbe PR gemergt, zwei Kommentare,target/ignoriert.Nicht geprüft:
clippyrot und „Code ohne Tests“ gegen den echten Forgejo (nur in den Tests mit Fake, die Logik ist dieselbe); ein echter Merge-Konflikt; ein Repo in einem fremden Konto statt in der Organisation; ob ein Admin-Token den Schutz bei einem PR-Merge anders behandelt als ein normaler Token (der Echtlauf lief mit Alfs Token).Grenzen: Der Echtlauf lief über
http://docker:3000, nicht über die öffentliche HTTPS-Adresse.Offen: Bauabschnitte 4 bis 8. Nächster Zug: Bauabschnitt 4 (grill, Beschreibung, Schritte).
PR #396 gemergt: feat(iris-rustapp-crafter): grill-me, Beschreibung und Schritte mit Abnahme (#388)
http://docker:3000/iris/iris-plugins/pulls/396
Commits:
Stand
Befund: Bauabschnitt 4 von
iris-rustapp-crafterist gebaut: grill-me mit Protokoll, Projektbeschreibung und Schrittliste mit Abnahme, jeweils mit Vorlage, Prüfung und Freigabe nur nach bestandener Prüfung.Geändert:
rc_grill.py(Protokoll.crafter/grill.json, sieben Pflichtthemen),rc_plan.py(Beschreibungplan/projekt.md, Schritteplan/schritte.json), Prüfer vor den Freigabe-Befehlen inrc_kern.py(FREIGABE_PRUEFER), neue Befehlegrill,beschreibung,schritteim Skript, Befehlstabelle der Stufen ergänzt;tests/test_planung.py; ein Test intest_kern.pyan die neue Prüfung angepasst;PLAN.mdundsession-kontext.mdnachgezogen.Geprüft: 151 Tests grün (auch mit
-W error::ResourceWarning), davon 38 neu: Einträge brauchen Frage, Empfehlung und Antwort; ein Pflichtthema entfällt nur mit Begründung und nur, wenn es eines ist;grill-fertignennt die offenen Themen und setzt dann keine Freigabe; eine spätere Änderung am Protokoll oder an Beschreibung und Schritten wirft die Stufe zurück; beschädigtes oder fremdes Protokoll bleibt unverändert; Vorlagen überschreiben nichts und bestehen die Prüfung erst, wenn jedes TODO ersetzt ist; die Beschreibung nennt alle Befunde auf einmal (fehlende oder zu kurze Abschnitte, Panelarten-Regeln); Schritte: eindeutige IDs, Abhängigkeiten nur nach hinten (auch kein Selbstbezug), Pflichtfelder, Panelarten nur aus der Beschreibung, ein Schritt ohne Abnahme ist nicht freigebbar, Abnahme-Befehle ohne Shell-Operatoren und nur mit erlaubten Programmen;schritte pruefenändert keine Datei. Gegenprobe: Ohne verdrahtete Prüfer schlagen fünf Tests an, mit erlaubten Shell-Operatoren schlägt der Abnahme-Test an; danach zurückgesetzt.Nicht geprüft: Im Gespräch mit einem LLM (ob es Vorlagen und Pflichtthemen wie gedacht nutzt); die Abnahme-Befehle werden hier nur geprüft, ausgeführt erst im Ausführen (Bauabschnitt 7); die Beschreibung und die Schrittliste sind noch nicht über
sendenin den Forgejo gewandert (das ist die Planungs-PR-Regel aus dem Plan,01-planung, und kommt mit dem Zusammenspiel in Abschnitt 7/8).Grenzen: Die sieben Pflichtthemen und die Pflichtabschnitte der Beschreibung sind fest im Code; ein Projekt mit anderem Bedarf braucht eine Änderung am Plugin. Die Mindestlängen (20 Zeichen je Abschnitt, 10 für eine Begründung) fangen nur offensichtlich leere Texte ab, keine inhaltlich dünnen.
Offen: Bauabschnitte 5 bis 8. Nächster Zug: Bauabschnitt 5 (
iris-claude-execim Plugin).PR #397 gemergt: feat(iris-rustapp-crafter): Claude-Code-Läufer mit Provider und Proxy im Hintergrund (#388)
http://docker:3000/iris/iris-plugins/pulls/397
Commits:
Stand
Befund: Bauabschnitt 5 von
iris-rustapp-crafterist gebaut: Aufträge an Claude Code laufen im Hintergrund, mit dem Provider und Modell aus der Plugin-Konfiguration und ohne Abfrage bei Iris (eigene Fassung voniris-claude-exec).Geändert:
rc_claude.py(Provider-Umgebung, Proxy-Start, Jobs, Läufer),rc_proxy.py(eigene Kopie des Anthropic→OpenAI-Proxys, Stand 2026-11-12), Befehljob starten|status|warten|abbrechen,.crafter/jobs/in.gitignore(beieinrichtenund beim ersten Job);tests/test_claude.pymittests/fake_claude.py;PLAN.md(Abschnitt 5, zwei Lektionen) undsession-kontext.mdnachgezogen.Geprüft: 181 Tests grün (30 neu): Provider-Umgebung je Art (Konto: Reste und Shell-Schlüssel entfernt; lokal: alle Modellnamen, Fenster- und Ausgaberegeln), ganze Kette
claude→ Proxy → falsches OpenAI-Backend, Schlüssel geht nur als Bearer ans Backend und steht weder in Argumenten, Umgebung vonclaude, Job-Dateien, Logs noch in der Prozessliste, Proxy endet mit dem Läufer, Auftrag nur über Stdin,--resume, Fehler und kaputte Ausgabe, fehlendesclaude, nicht startbarer Proxy, Zeitlimit, Abbruch, toter Läufer, Kennungen gegen Pfadtricks, Jobs zählen nicht zum Fingerabdruck. Gegenproben: Schlüssel im Proxy-Argument macht den Test rot. Echtprobe mit dem echtenclaude(Claude-Konto, Scratchpad-Workspace): Auftrag über Stdin, JSON und Sitzungs-ID ausgewertet; Datei angelegt,git commitverweigert (kein Commit entstanden);--resumesetzt die Sitzung mit Kontext fort („x.txt“).Nicht geprüft: Die Proxy-Kette mit einem echten lokalen Modell (auf diesem Rechner läuft kein LM Studio oder Ollama; nur gegen ein falsches Backend, ohne Streaming);
basis-urlgegen einen echten Cloud-Anbieter; die Werkzeugrechte als Sicherheitsgrenze (eine Regel für Claude Code, keine Sandbox); Windows (der Proxy brauchtfork); ein langer Auftrag mit echten Werkzeugen (cargo) im Läufer.Gefunden: In
~/.zshrcist einANTHROPIC_API_KEYexportiert. Er überstimmt die Anmeldung von Claude Code (Warnung „claude.ai connectors are disabled because ANTHROPIC_API_KEY … is set“) und hatte laut Antwort kein Guthaben („Credit balance is too low“): Der erste Echtlauf schlug deshalb fehl. Der Läufer entfernt den Schlüssel für das Claude-Konto jetzt; die~/.zshrchabe ich nicht angefasst. Außerdem fand der Test mit dem echten Prozess, dass ein mitpython3 -Igestartetes Modul seine Nachbarmodule nicht findet.Grenzen: Wer mit einem Anthropic-API-Schlüssel statt der Anmeldung arbeiten will, hat dafür noch keinen Provider (der Proxy übersetzt nur nach OpenAI). Die Kopie des Proxys wird nicht mit dem Original abgeglichen.
Offen: Bauabschnitte 6 bis 8. Nächster Zug: Bauabschnitt 6 (Figcraft).
PR #398 gemergt: feat(iris-rustapp-crafter): eigenes iris-claude-exec setzt Provider und Modell aus der Konfiguration (#388)
http://docker:3000/iris/iris-plugins/pulls/398
Commits:
Stand
Befund: Alf bemängelte, dass im Normalbetrieb nicht einfach
claudeaufgerufen werden darf, sondern dasiris-claude-exec-Skript, das das LLM aus der Plugin-Konfiguration nimmt. Mein Läufer (Bauabschnitt 5) enthielt die Provider-Logik selbst und riefclaudedirekt auf; ein eigenständiges Skript, das auch andere Werkzeuge verwenden können, fehlte.Geändert: Neu
rc_exec.py, dasiris-claude-execdes Plugins: liest Provider und Modell nur aus der Plugin-Konfiguration, ersetzt ein vom Aufrufer übergebenes--modeldurch das konfigurierte, setzt die Umgebung je Provider, startet beilokalundbasis-urlden Proxy und ersetzt sich perexecdurchclaude(der Proxy beobachtet dieselbe PID und endet mitclaude).rc_claude.pyruft nur noch dieses Skript auf und hat keine Provider-Logik mehr. Neuer Befehlexec-pfad(Befehl für andere Werkzeuge).tests/test_exec.py(23 Tests),tests/test_claude.pyangepasst, Test-SchalterRUSTAPP_CRAFTER_PROXY;PLAN.mdundsession-kontext.mdnachgezogen.Geprüft: 204 Tests grün (auch gegen den Läufer: der Läufer startet nur
rc_exec.py, nieclaude; das konfigurierte Modell erscheint genau einmal in den Argumenten).modell_argumente: ersetzt--model Xund--model=X, ergänzt es, lässt ohne konfiguriertes Modell alles, mehrfach,--modelohne Wert, Eingabe unverändert. Claude-Konto: Argumente unverändert durchgereicht, Shell-Schlüssel und Proxy-Reste entfernt, kein Proxy. Lokal: Proxy, alle Modellnamen, Fenster, ganze Kette bis zum falschen OpenAI-Backend, Proxy endet mitclaude. Schlüssel nur als Bearer ans Backend, nie in Argumenten, Prozessliste, Umgebung vonclaude, Ausgabe oder Proxy-Log.--version/--helpohne Konfiguration; unvollständiger Provider und beschädigte Konfiguration: Exit 1 ohne Start vonclaude;claudenicht gefunden: 127; Exit-Code vonclaudewird durchgereicht. Gegenprobe: ohne erzwungenes Modell schlagen acht Tests an. Echtprobe mit dem echtenclaude: Der Auftrag mit übergebenem--model claude-opus-5-5lief lautmodelUsagemit dem konfiguriertenclaude-haiku-4-5;--versiongeht durch; ohne Provider scheitert das Skript klar.Nicht geprüft: Die Proxy-Kette mit einem echten lokalen Modell (auf diesem Rechner läuft keines) und
basis-urlgegen einen echten Anbieter; Einbindung in ein fremdes Werkzeug (zum Beispiel als Backend in Craft Anything); Windows.Unerklärt: Beim ersten Lauf von
test_exec.pyschlug einmal der Test „Schlüssel nicht in der Prozessliste“ an. Ich konnte das nicht wiederholen (danach über 15 Läufe grün, auch mit ständiger Beobachtung der Prozessliste); die Ursache habe ich nicht gefunden. Ein Beobachter mitgrepauf den Schlüssel erzeugt selbst einen Treffer (Messfehler). Die Fehlermeldung des Tests nennt jetzt die gefundenen Zeilen mit geschwärztem Schlüssel, damit ein Wiederauftreten klärbar ist.Grenzen: Die Werkzeugrechte sind eine Regel für Claude Code, keine Sandbox. Ein Anthropic-API-Schlüssel statt der Anmeldung hat keinen Provider.
Offen: Bauabschnitte 6 bis 8. Nächster Zug: Bauabschnitt 6 (Figcraft).
PR #399 gemergt: feat(iris-rustapp-crafter): GUI-Entwurf in Figcraft mit Export und Prüfung (#388)
http://docker:3000/iris/iris-plugins/pulls/399
Commits:
Stand
Befund: Bauabschnitt 6a von
iris-rustapp-crafterist gebaut: der GUI-Entwurf in Figcraft mit deterministischem Export und Freigabe-Prüfung. Er braucht weder MCP noch die Desktop-App, nur das headlessfigcraft-cli(info --json,export,convert,run). Das Folge-Issue für den Upload in die Registry ist angelegt: alf/2ndbrain#196.Geändert:
rc_gui.py, Befehlegui vorlage|export|pruefen|pfad, Prüfer fürgui-freigeben, Test-Helfergui_export_schreiben,tests/test_gui.py(26 Tests),test_planung.pyauf den neuen Helfer umgestellt;PLAN.md(6 in 6a/6b/6c geteilt, Lektion) undsession-kontext.mdnachgezogen.gui vorlagelegtgui/<projekt>.figcraftan: ein Frame je Panelart der Beschreibung, dazu die 18--pk-*-Tokens von panel-kit als Variablen (hell/dunkel), Füllung und Text an die Tokens gebunden.gui exportschreibt je Frame ein PNG (Standard 2x),design.json,tokens.json(Variablen → CSS je Modus) undmanifest.json(Hash des Entwurfs, ohne Zeitstempel).Geprüft: 230 Tests grün, 26 davon neu und die meisten mit dem echten
figcraft-cli0.17.1 (Entwicklungs-Build; übersprungen, wenn er fehlt): Vorlage mit den richtigen Frames und allen 18 Tokens; Export liefert PNG je Frame in 2x, die richtigen Hell/Dunkel-Werte (--pk-bghell #E4E6EA, dunkel #14161A) und ein Manifest; erneuter Export ergibt denselben Fingerabdruck; ein nach dem Export geänderter Entwurf wird erkannt; ein umbenannter oder doppelter Frame verhindert den Export und lässt nichts zurück; ein alter Export wird vollständig ersetzt; Freigabe nur mit stimmigem Export, eine Änderung danach wirft die Stufe zurück;figcraft-clifehlt oder fällt aus: klare Meldung. Gegenproben: ohne Hash-Prüfung zwei Tests rot, mit--no-system-fontsder Test „Text im PNG sichtbar“.Gefunden: (1)
~/Desktop/Figcraft.app/Contents/MacOSenthält nurFigCraft; dasfigcraft-cliwird mitgebaut (target/aarch64-apple-darwin/release/figcraft-cli, 46 MB), aber nicht ins Bundle gelegt (Upstream schreibt es als eigenes ZIP). Das gehört in alf/2ndbrain#196. (2) Mit--no-system-fontswaren Texte im Export unsichtbar (Inter ist nicht eingebaut): Beim Ansehen des gerenderten Bildes fielen leere Frames auf, die Tests hatten nur Größe und Namen geprüft. Der Schalter ist entfernt, ein Test prüft jetzt Inhalt im PNG.Nicht geprüft: Ob die Figcraft-Desktop-App die vom CLI geschriebene Datei öffnet und die Token-Bindung zeigt (die App lief nicht mit Steuerkanal, der Zugriff schlug fehl); ob Änderungen aus der App später sauber exportieren; Gleichheit der PNGs zwischen zwei Rechnern (auf demselben Rechner byte-gleich); die Schrift Inter ist auf diesem Mac nicht installiert (Ersatzschrift, das Manifest nennt sie).
Grenzen: Frames müssen auf der ersten Seite liegen und genau so heißen wie die Panelarten. Die Token-Standardwerte sind aus dem Stylesheet von panel-kit kopiert (Stand 2026-11-12) und werden nicht abgeglichen.
Offen: 6b (Installation aus der Registry, wartet auf alf/2ndbrain#196), 6c (MCP-Einträge), Bauabschnitte 7 und 8. Das
figcraft-climuss bis 6b selbst bereitstehen (RUSTAPP_CRAFTER_FIGCRAFT_CLI).PR #400 gemergt: feat(iris-rustapp-crafter): Figcraft per MCP für Claude-Code-Jobs und Hermes (#388)
http://docker:3000/iris/iris-plugins/pulls/400
Commits:
Stand
Befund: Bauabschnitt 6c von
iris-rustapp-crafterist gebaut: Figcraft ist als MCP-Server für Claude Code (je Job) und für Hermes anschließbar, mit begrenztem Dateizugriff. Der Server ist das headlessfigcraft-cli mcp(19 Werkzeuge).Geändert:
rc_figcraft_mcp.py;rc_claude.py(Optionfigcraft:mcp.jsonje Job,--mcp-config,--strict-mcp-config, Rechtmcp__figcraft), Befehlejob starten --figcraftundfigcraft hermes-registrieren|hermes-entfernen|hermes-status|mcp-json;tests/test_mcp.py(22 Tests);PLAN.mdundsession-kontext.mdnachgezogen. Der Zugriff ist begrenzt: Lesen im Workspace, Schreiben nur ingui/. Für Hermes:hermes mcp add figcraft-crafter(wieiris-solidcraft, mit „Y“, Erfolg nur bei „Saved“); der Eintrag ist global, deshalb ist--wurzelPflicht, und das Gateway wird nur mit--neustartenneu gestartet.Geprüft: 252 Tests grün. Mit dem echten
figcraft-cli(MCP über stdio, JSON-RPC): 19 Werkzeuge sind da; Lesen außerhalb des Workspace und Schreiben außerhalb vongui/werden mit „automation path rejected“ abgelehnt, Schreiben ingui/geht; ein Agent kann im Entwurf arbeiten und speichern, das CLI liest die Änderung danach. Hermes mit einem falschenhermes: erstremovedes eigenen Namens, dannaddmit Eingabe „Y“, nur der eigene Name wird angefasst, kein Neustart ohne--neustarten,--wurzelPflicht und muss existieren,add-Fehler und fehlendeshermesoderfigcraft-cliwerden klar gemeldet. Gegenproben: Schreibwurzel = ganzer Workspace macht zwei Tests rot,hermes mcp addohne „Y“ drei. Echtprobe mit dem echten Claude Code und dem echtenfigcraft-cliim Scratchpad: Der Job mit--figcraftöffnete den Entwurf, nannte die zwei Frames, legte „zusatz“ an und speicherte (der Frame steht danach in der Datei); das Speichern nachplan/wurde verweigert, die Datei existiert nicht.Nicht geprüft: Die echte Registrierung in Hermes habe ich bewusst nicht ausgeführt: Sie ändert die produktive
~/.hermes/config.yamlund mit--neustartendas Gateway; geprüft habe ich nur das falschehermesund lesendhermes mcp list(kein Figcraft-Eintrag vorhanden). Offen ist außerdem, ob Hermes die Werkzeuge danach im Chat nutzt, welcher Ordner als--wurzelfür die Chat-Arbeitsbereiche passt (unter~/Library/Application Support/Irisnicht gefunden) und wie sich ein lokales Modell mit den 19 Werkzeugbeschreibungen verhält.Grenzen: Die Begrenzung gilt für den headless Server; ein Server im Anschluss-Modus an die laufende App (
--attach) wird von der App begrenzt, nicht von diesen Optionen.--strict-mcp-configblendet im Job alle anderen MCP-Server aus.Offen: 6b (Installation, wartet auf alf/2ndbrain#196), Bauabschnitte 7 und 8. In Abschnitt 7 entscheidet die Schrittliste (Panels, GUI-Abnahme), welcher Job
--figcraftbekommt.PR #401 gemergt: feat(iris-rustapp-crafter): Ausführung 7a mit Planungs-PR, Auftrag und Start der Schritte (#388)
http://docker:3000/iris/iris-plugins/pulls/401
Commits:
Stand
Befund: Etappe 7a der Ausführungsschleife von
iris-rustapp-crafterist gebaut: Zustand je Schritt, Planungs-PR, Auftrag, Issue je Schritt und Start des Jobs. Das Skript führt (Reihenfolge, Auftrag, Issue), das LLM beurteilt erst ab 7b.Geändert: Neu
rc_ausfuehrung.pymitausfuehren status|planung|start;rc_senden.py(issue_erstellengibt die Issue-Nummer zurück),rc_forgejo.py(Git-Ausgaben tolerant dekodiert), Stufentabelle (ausführenverlangt die Markierungplanungvorausgefuehrt);tests/test_ausfuehren.py(23 Tests);PLAN.mdundsession-kontext.mdnachgezogen.planungreicht Grill-Protokoll, Beschreibung, GUI-Entwurf und Schrittliste als eigenen PR ein: Issuetyp/docs, Standkommentar aus den Fakten (Freigaben mit Wortlaut und Zeit, was das Skript geprüft hat, ehrlich: ob der Plan inhaltlich richtig ist, hat der Nutzer freigegeben, das Skript beurteilt es nicht).startwählt den nächsten Schritt der Reihenfolge nach (ein Halt blockiert, nichts wird übersprungen), nur aufmain, legt das Issue an (nicht doppelt bei Wiederaufnahme), baut den Auftrag deterministisch, hält die Fingerabdrücke von Beschreibung, Schritten, Grill und GUI fest und startet den Job, mit Figcraft nur bei Panels oder GUI-Abnahme.Geprüft: 276 Tests grün (zuletzt in 135 Sekunden), darunter 23 neue gegen Fake-Forgejo und falsches
claude: Planungs-PR mit allen Plan-Dateien inmainund ohne Hilfsdatei, Issue und Standkommentar (alle Pflichtabschnitte, Wortlaut der Freigaben, keinstatus/zu-testen), zweiter Aufruf ändert nichts, verweigerter Merge setzt keine Markierung, Planung nur in der Stufeausführen; Auftrag mit Schritt, Abnahme, Regeln, Verweisen auf PNG und Tokens, ohne absolute Pfade und Geheimnisse, deterministisch; Start: Issue mit Labeltyp/feature, Job gestartet, Zustand gemerkt, Reihenfolge erzwungen, nicht außerhalb vonmain, Wiederaufnahme ohne doppeltes Issue, Fehler vor dem Jobstart lässt den Schritt offen, beschädigter oder abweichender Zustand wird nicht überschrieben. Gegenprobe: Reihenfolge nicht erzwungen macht den Test rot; ohne tolerante Dekodierung bricht der neue Test.Gefunden: (1)
sendenlas Git-Ausgaben als striktes UTF-8; Git gibt Dateien ohne NUL-Byte als Text aus, ungültiges UTF-8 darin (zum Beispiel Latin-1) brach den PR ab. Meine erste Erklärung (echte PNGs brächen es) war falsch: Echte PNGs enthalten NUL-Bytes und erscheinen nur als „Binary files differ“; es waren meine Test-PNGs ohne NUL. Behoben mit toleranter Dekodierung und einem Test mit Latin-1. (2) Die Stand-Hilfsdatei des Planungs-PRs lag im Workspace und wäre mitgit add -Ain den PR gewandert; sie liegt jetzt in einem temporären Ordner.Nicht geprüft: Gegen einen echten Forgejo und mit echtem Claude Code ist die Ausführung noch nicht gelaufen (kommt nach 7b als Echtlauf); die Planungs-PRs mit echten PNGs und großem Design-JSON (Größe und Dauer); ob
status/zu-testenfür Planungs-PRs fehlen soll (so entschieden, weil nichts „gebaut, aber nicht ausprobiert“ ist).Grenzen: Der Schritt-Status
gesendetund der Zustand der Ausführung ziehen erst mit dem nächsten PR inmain(der Zustand nach dem Merge ist lokal geändert, aber nicht committet); auf einem anderen Rechner kann der letzte Schritt deshalb noch „gesendet“ statt „gemergt“ heißen.Offen: 7b (
pruefen,bericht,beurteilen,nachbessern,weiter,senden, Markierungausgefuehrt), Bauabschnitt 8, 6b. Nächster Zug: 7b.PR #402 gemergt: feat(iris-rustapp-crafter): Ausführung 7b mit Prüfen, Urteil, Nachbessern, Halt und Senden (#388)
http://docker:3000/iris/iris-plugins/pulls/402
Commits:
Stand
Befund: Etappe 7b der Ausführungsschleife von
iris-rustapp-crafterist gebaut: Prüfen, Bericht, Urteil, Nachbessern, Halt und Senden eines Schritts. Damit ist die Schleife vollständig: planen, starten, prüfen, beurteilen, (nachbessern | senden) bis zur Abnahme.Geändert:
rc_ausfuehrung.pyumausfuehren pruefen|bericht|beurteilen|nachbessern|weiter|sendenerweitert; Befehlstabelle der Stufeausführen;tests/test_schleife.py(40 Tests);PLAN.mdundsession-kontext.mdnachgezogen.pruefenhält zuerst fest, ob Claude Code Plan-Dateien, Grill-Protokoll, GUI-Entwurf oder die Freigaben in.crafter/state.jsongeändert hat (dann Halt, nichts wird zurückgesetzt), und führt sonst die feste Rust-Prüfung, die Abnahme-Befehle (ohne Shell), die Testpflicht und „der Schritt hat etwas geändert“ aus.beurteilenverlangt eine Begründung;okgeht nur bei grünen Belegen und, bei GUI-Abnahme, mit jedem verglichenen Bild; nach zwei erfolglosen Versuchen gibt es einen Halt.nachbessernsetzt die Sitzung mit dem Hinweis aus dem Urteil fort.weiter --wortlautist die Entscheidung des Nutzers nach einem Halt (nur bei wiederhergestelltem Plan).sendenschickt den beurteilten Schritt als PR; der Standkommentar entsteht aus den Fakten und nennt unter „Nicht geprüft“ ehrlich: nicht von Hand ausprobiert, der Bildvergleich stammt vom Modell (kein Pixelvergleich, nicht vom Nutzer). Nach dem letzten Schritt setzt es die Markierungausgefuehrt.Geprüft: 316 Tests grün (zuletzt in 229 Sekunden), davon 40 neu in
tests/test_schleife.py(Fake-Forgejo, falschesclaude): grüner Schritt mit allen Belegen; rote Rust-Prüfung, rote Abnahme, Code ohne Tests, Schritt ohne Änderung, fehlgeschlagener Job; Abnahme-Befehle ohne Shell; Halt bei Änderung anplan/projekt.md,plan/schritte.json,.crafter/grill.json,gui/und gefälschtem Wortlaut der Freigaben, ohne etwas zurückzusetzen und ohne weiterzuprüfen; Start nach Halt gesperrt;weiternur mit Wortlaut und wiederhergestelltem Plan; Bericht mit den Fakten; Urteil: Begründung und Status Pflicht,oknur bei grünen Belegen, Bilder bei GUI-Abnahme, zwei Versuche dann Halt; Nachbessern mit--resumeund Hinweis; Senden: nur beigeprueftundok, Code nach der Prüfung geändert wird erkannt, Merge, Labelstatus/zu-testen, Issue bleibt offen, Standkommentar mit allen Pflichtabschnitten und den Fakten, der Zustandgesendetsteht im PR, roter Lauf oder verweigerter Merge setzt aufgeprueftzurück; der ganze Weg beider Schritte bis zur Abnahme (Schritt 2 mit Figcraft-Job, abgelehntem Code ohne Test, Nachbessern, Bildvergleich, Merge,ausgefuehrt,abnahmedurch den Nutzer); ein Weg über die Befehle mit einem falschencargo.Gefunden: Ändert Claude Code Plan-Dateien, fällt die Stufe über die Fingerabdrücke zurück; mein
pruefenverlangte aber zuerst die Stufe und parste den Plan, sodass der Halt mit seiner Erklärung nie festgehalten wurde. Er wird jetzt ohne Planprüfung aus dem rohen Zustand gesetzt (roh_laden), auch bei unlesbarem Plan; bei geändertem Plan sperrt zusätzlich die Stufe (Test). Vor dem erstenstartgibt es keine Zustandsdatei:pruefenundweitermeldeten das irreführend als „nicht lesbar“, jetzt klar „noch kein Schritt gestartet“. Außerdem lehnte im Gesamtweg die Testpflicht zu Recht Schritt 2 ohne neuen Test ab (der Test deckt jetzt den Weg über Nachbessern ab).Nicht geprüft: Der Bildvergleich selbst: Es gibt weder einen Pixelvergleich noch einen Screenshot der gebauten Oberfläche; „Bilder verglichen“ ist eine Aussage des LLM, die das Skript nur einfordert, nicht belegen kann. Mit echtem Claude Code und gegen einen echten Forgejo ist die Schleife noch nicht gelaufen (Echtlauf als Nächstes). Ob das LLM die Befehle im Gespräch richtig benutzt (Skill und Systemprompt fehlen noch, Bauabschnitt 8).
Grenzen:
gesendetund der Zustand nach dem Merge ziehen erst mit dem nächsten PR inmain. Die Werkzeugrechte von Claude Code sind eine Regel, keine Sandbox: Das Skript erkennt Änderungen an Plan und Freigaben nur im Nachhinein (Halt), verhindert sie nicht.Offen: Echtlauf der Schleife (echter Claude Code, Wegwerf-Repo, kleines Rust-Projekt), Bauabschnitt 8 (Skill, Systemprompt, Panel, Doku, Linux-Test), 6b. Nächster Zug: Echtlauf.
PR #403 gemergt: fix(iris-rustapp-crafter): Echtlauf der Schleife, Issues mit pull_request null und wiederholbare Planung (#388)
http://docker:3000/iris/iris-plugins/pulls/403
Commits:
Stand
Befund: Echtlauf der ganzen Ausführungsschleife von
iris-rustapp-craftergegen den eigenen Forgejo, mit echtem Claude Code (claude-haiku-4-5, Claude-Konto), echtemcargound echtemfigcraft-cli, in einem Wegwerf-Repoiris/crafter-schleife-test(danach gelöscht: DELETE 204, danach 404; die Konfigurationsdatei mit dem Token im Scratchpad ist entfernt). Die Schleife läuft vom Einrichten bis zur Abnahme durch; dabei ein Fehler gefunden und behoben.Geändert:
rc_senden.py(ein Issue gilt als PR nur, wennpull_requestein Objekt ist, nicht beinull),rc_ausfuehrung.py(die Nummer des Planungs-Issues steht im Zustand und wird nach einem Fehlschlag wiederverwendet), Fake-Forgejo intests/helfer.py(liefert beide Formen wie Forgejo), je ein neuer Test intest_senden.pyundtest_ausfuehren.py;PLAN.md(Echtlauf, Lektion) undsession-kontext.md.Geprüft (Echtlauf):
konfig pruefen,einrichten, Grill mit 7 Themen, Beschreibung,gui vorlage|export|pruefenmit dem echten CLI, Schrittliste mit 2 Schritten,ausfuehren planung(PR #3, Issue #2typ/docs), Schrittkern(Job 12 Züge/30 s/0,08; `pruefen` mit echtem `cargo`: fmt, clippy, test und Abnahme grün, Tests dabei; Bericht; Urteil ok nach Durchsicht des Codes; `senden`: PR #5 gemergt per Rebase, Issue #4 offen mit `status/zu-testen`), Schritt `liste` mit Figcraft-Job (21 Züge/55 s/0,11; 8 neue Tests, keine bestehenden entfernt; PR #7, Issue #6), danach Stufeabnahme. Unabhängig per API: vier Commits per Rebase aufmain, drei gemergte PRs, nur der Branchmain, Issues offen mit den richtigen Labels (das Planungs-Issue ohnezu-testen), Standkommentar aus den Fakten mit Belegen und ehrlichem „Nicht geprüft“. Gesamtkosten des echten Claude Code: 0,19 $. Die Freigaben des Nutzers hat der Test-Treiber selbst gesetzt, mit dem Zusatz „Echtlauf-Treiber … (kein echtes Urteil des Nutzers)“. Danach: 318 Tests, im Gesamtlauf 316 grün; zwei Tests setzten voraus, dass die Zustandsdatei vor dem erstenstartfehlt (seitplanunggibt es sie), ihre Erwartungen sind angepasst und laufen einzeln grün.Gefunden: (1) Mein Fix aus dem ersten Echtlauf war falsch. Forgejo liefert bei echten Issues
"pull_request": null; mein Test"pull_request" in …hielt jedes Issue für einen PR,ausfuehren planungscheiterte sofort mit „#1 ist ein Pull Request, kein Issue“. Der Fake bildete nur den PR-Fall ab, deshalb sahen alle Tests grün aus. Behoben, mit Gegenprobe (der alte Test schlägt an). (2)planungwar nach einem Fehlschlag nicht wiederholbar, ohne ein zweites Planungs-Issue anzulegen; jetzt wird die Nummer wiederverwendet. (3) Claude Code hat die Figcraft-Werkzeuge im Schrittlistenicht benutzt, obwohl verfügbar: Der Auftrag verwies nur auf das PNG; das ist kein Fehler, aber gut zu wissen.Nicht geprüft: Der Bildvergleich (der Lauf hatte keine GUI-Abnahme); ob ein anderes oder ein lokales Modell dieselben Aufträge erfüllt; Aufträge mit Abhängigkeiten (panel-kit, Leptos, wasm); ein durchgefallener Schritt und das Nachbessern mit echtem Claude Code (beide echten Schritte bestanden im ersten Versuch; nur mit dem falschen
claudegetestet);abnahmedurch den Nutzer und das Schließen der Issues (bleibt beim Nutzer).Grenzen: Der Echtlauf lief mit einem kleinen Auftrag (zwei Schritte, eine Bibliothek ohne Abhängigkeiten) und mit deinem Token über
http://docker:3000.Offen: Bauabschnitt 8 (Skill, Systemprompt, Einstellungs-Panel, Doku, Linux-Test), 6b (wartet auf alf/2ndbrain#196).
PR #404 gemergt: feat(iris-rustapp-crafter): Paket 0.1.0 mit Skill, Einstellungsfenster, Anleitung und Store (#388)
http://docker:3000/iris/iris-plugins/pulls/404
Commits:
Stand
Befund: Bauabschnitt 8a von
iris-rustapp-crafterist gebaut: Das Plugin ist als Paket installierbar (Version 0.1.0): Manifest, Skill, Systemprompt, Einstellungsfenster mit Verbindungstest, Anleitung, Build und Store-Material. Der Trockenlauf vonpublish-plugins.shist grün.Geändert:
plugin.json(Kategoriedevelopment, nur Mac,panel_apimitconfig-status,status,save,test,figcraft-status),skills/iris-rustapp-crafter/SKILL.md,system_prompt.md,web/settings.html,panel_api.py(neu:test,figcraft-status), drei Anleitungsseiten,build-irisplugin.sh,store/(Langtext, Changelog, Icon, Seite),store-page.json,.include;tests/test_panel.py,test_settings_html.py,test_paket.py;PLAN.mdundsession-kontext.md. Abweichung vom Plan: Die Abfrage der Konfiguration per Canvas ist durch das Einstellungsfenster ersetzt; im Chat setzt Iris nur Nicht-Geheimnisse, Token und Schlüssel trägt der Nutzer im Fenster ein.Geprüft: 356 Tests grün (zuletzt in 248 Sekunden), davon 38 neu. Panel:
testliest nur (kein Schreibaufruf an Forgejo), Felder im Body gelten nur für den Test, falsches Token, fehlende Angaben, Claude nicht gefunden, lokaler Server mit Modellliste und Kontextfenster, nicht erreichbarer Server, Schlüssel geht nur als Bearer ans Backend und nie in die Antwort, Figcraft gefunden mit Version und~statt des Heimatordners. Einstellungsfenster (Node): Status ohne Geheimnisse, Speichern sendet nur ausgefüllte Geheimnisse, danach sind die Felder leer, Fehler und rote Testschritte werden angezeigt. Paket: Manifest, Skill-Frontmatter, keine Namenskollision mit Hermes' Skills, Befehle in Anleitung und Skill gibt es wirklich, Paketinhalt und -größe (80 KB), keine Heimatpfade und Geheimnisse; das entpackte Paket läuft ohne das Repo (Befehle, Panel-API,rc_exec.py,rc_proxy.py). Gegenproben: ein Import eines nicht gepackten Moduls und ein erfundener Befehl in der Anleitung machen je einen Test rot;ok:falseals Fehler im Fenster macht den Test rot. Trockenlauf./publish-plugins.sh --dry-run iris-rustapp-crafter: baut, 1 würde veröffentlicht, 0 Fehlschläge (Datenschutz-Scan inklusive).Gefunden: (1) Das Einstellungsfenster behandelte jede Antwort mit
ok: falseals Fehler; der Befehltestmeldet rote Schritte genau so, die Liste wäre nie erschienen (der Node-Test fand es). (2) Die Panel-Aufrufe erbten Stdin: Ein Prozess, der es liest, hängt bis zum Zeitlimit; jetztstdin=DEVNULL.Nicht geprüft: Die Installation in der echten Iris (Mac-GUI) und der Aufruf der Panel-Befehle von dort; das Einstellungsfenster im echten Plugin-Manager (nur im Node-Modell); ob Hermes den Skill im Gespräch richtig benutzt und die Auto-Auswahl des Systemprompts greift; Linux; ob ein Update-Dialog den Änderungstext zeigt.
Grenzen: Nur Mac. Figcraft muss bereitstehen (die automatische Installation wartet auf alf/2ndbrain#196). Der Bildvergleich ist eine Aussage des LLM, kein Pixelvergleich.
Offen: Veröffentlichung (nach deiner Regel für Plugin-Versionen: Tests grün, Trockenlauf grün; der Stand der Veröffentlichung folgt als eigener Kommentar im selben Zug), Installation und Chat-Durchlauf in der echten Iris, 6b.
Stand: veröffentlicht
Befund:
iris-rustapp-crafter0.1.0 ist in der Plugin-Registry veröffentlicht, nach deiner Regel für Plugin-Versionen (Tests grün, Trockenlauf grün, Stand im Issue).Geprüft: Nach einem frischen Pull des Registry-Repos: Commit
6c95428 plugins: iris-rustapp-crafter 0.1.0auforigin/main;index.jsonnenntiris-rustapp-crafterin Version 0.1.0 (Kategoriedevelopment, Plattformmacos, Name „Rust-App-Werkstatt“, Änderungstext vorhanden), jetzt 30 Plugins;packages/iris-rustapp-crafter/iris-rustapp-crafter-0.1.0.irispluginsowiestore/iris-rustapp-crafter/mit Anleitung, Changelog, Langtext, Seite und Icon liegen im Repo. Der Datenschutz-Scan des Skripts hat nichts gefunden.Was Nutzer bekommen: Das Plugin erscheint im Marktplatz (nur auf dem Mac installierbar): Rust-Apps mit Panel-Oberfläche in Stufen planen, in Figcraft entwerfen und von Claude Code schrittweise bauen lassen; Einstellungsfenster, Anleitung (3 Seiten), Skill und Systemprompt.
Nicht geprüft: Die Installation aus dem Marktplatz in einer echten Iris (Mac-GUI), die Panel-Aufrufe von dort und ein Chat-Durchlauf mit Hermes (ob der Skill richtig benutzt wird, ob die Auto-Auswahl des Systemprompts greift); Linux.
Grenzen: Figcraft muss bereitstehen (die automatische Installation wartet auf alf/2ndbrain#196). Der Bildvergleich ist eine Aussage des LLM, kein Pixelvergleich.
Offen: Installation und Chat-Durchlauf in der echten Iris (dafür bitte
status/zu-testenim Blick behalten: Das Label und das Schließen dieses Issues bleiben bei dir), 6b, Linux.PR #405 gemergt: feat(iris-rustapp-crafter): Iris' eigener Forgejo im Einstellungsfenster wählbar, Version 0.1.1 (#388)
http://docker:3000/iris/iris-plugins/pulls/405
Commits:
Stand
Befund: Alf wünschte im Einstellungsfenster von
iris-rustapp-crafterdie einfache Auswahl von Iris' eigenem Forgejo, wie iniris-plugin-dev(Screenshots verglichen). Das war nicht vorhanden: Das Fenster verlangte immer Adresse und Token. Jetzt gibt es die zwei Karten „Iris' eigener Forgejo (dieser Rechner)“ und „Manueller Server“; Version 0.1.1.Geändert: Neu
rc_eigener.py(eigene Implementierung, kein Import ausiris-plugin-dev): Erkennung überIRIS_FORGEJO_*oderforgejo-admin.json(Adresse aus demurl-Feld, sonstROOT_URLderapp.ini, sonsthttp://127.0.0.1:3300), Anmeldung als Administrator per Basic für API und Git (kein Token nötig), CA des eigenen Forgejo.rc_forgejo.Forgejokann Token oder Basic und schwärzt Passwort und Kopfwert;rc_konfigmitforgejo.server(eigener|manuell, beieigenerkommt die Adresse aus dem System) undkonfig setzen --forgejo-server;rc_netzlädt die CA;panel_api.pymiteigenerim Status und dem neuen Befehlbesitzer;web/settings.htmlmit den zwei Karten, Adresse und Badge erreichbar/nicht erreichbar/nicht gefunden und Besitzer-Picker; Anleitung, Skill, Store-Texte undplugin.json(Version 0.1.1, Änderungstext); Fake-Forgejo kennt die Basic-Anmeldung;PLAN.mdundsession-kontext.md.Geprüft: 397 Tests grün (zuletzt in 268 Sekunden), darunter 33 neue in
tests/test_eigener.pyund erweiterte Fenster-Tests (19, Node): Erkennung über Umgebung und Datei (Vorrang, unvollständige oder kaputte Datei, URL-Reihenfolge), Basic-Kopf,erreichbarmit richtigem und falschem Passwort und ohne Server; die Konfiguration braucht beieigenerweder Adresse noch Token, die Adresse kommt aus dem System und nie aus dem Formular, Wechsel zurück zum manuellen Server behält das Token, ein später verlorener eigener Forgejo steht infehlt; API-Aufrufe nutzen Basic und kein Token, falsches Passwort wird klar gemeldet ohne das Passwort, Git bekommt den Kopf nur über die Umgebung (nie im Argument), CA wird gesetzt; der ganze Wegeinrichten, Issue undsendenmit dem eigenen Forgejo; Panel:statusmiteigener,besitzer(Organisationen und Konto),test,save; das Passwort steht in keiner Datei, keinem Status und keiner Antwort. Fenster: die Karten, Vorwahl des eigenen Forgejo, Badge, bei „nicht gefunden“ bleibt der manuelle Server gewählt, im eigenen Modus werden weder Adresse noch Token gesendet, der Besitzer-Picker. Gegenproben: ungeschwärzte Geheimnisse, Adresse aus dem Formular und Adresse im eigenen Modus gesendet machen je Tests rot.Gefunden: Auf Alfs Mac steht in
forgejo-admin.jsondie Adressehttp://forgejo:3300, die von hier aus nicht erreichbar ist: Das Fenster zeigt dann „nicht erreichbar“ (Fall getestet).Nicht geprüft: Gegen einen echten eigenen Forgejo von Iris (hier nicht erreichbar): die Anmeldung per Basic mit echtem Passwort, Git über HTTPS mit der CA, die Besitzer-Liste, das Fenster im echten Plugin-Manager. Geprüft ist nur gegen den Fake und lesend gegen die Datei.
Grenzen: Die Anmeldung des eigenen Forgejo ist die des Administrators: Das Plugin darf damit alles dort, nicht nur Repos anlegen.
Offen: Echtlauf mit dem eigenen Forgejo, sobald er erreichbar ist (Version 0.1.1 wird nach der Regel für Plugin-Versionen veröffentlicht, nach grünen Tests und Trockenlauf; der Stand folgt als eigener Kommentar).
Stand: 0.1.1 veröffentlicht
Befund:
iris-rustapp-crafter0.1.1 ist in der Plugin-Registry veröffentlicht (nach deiner Regel für Plugin-Versionen: 397 Tests grün, Trockenlauf grün, Stand im Issue).Geprüft: Nach einem frischen Pull des Registry-Repos: Commit
f254a15 plugins: iris-rustapp-crafter 0.1.1auforigin/main;index.jsonnennt Version 0.1.1 (Kategoriedevelopment, Plattformmacos, Änderungstext vorhanden), die Versionsliste enthält 0.1.0 und 0.1.1, undpackages/iris-rustapp-crafter/hat beide Pakete.Was Nutzer bekommen: Im Einstellungsfenster lässt sich Iris' eigener Forgejo mit einem Klick wählen: Er wird automatisch erkannt (Adresse und „erreichbar“ werden angezeigt), die Anmeldung übernimmt Iris, ein Token ist nicht nötig; der Besitzer der Repos kommt aus einer Liste. Für einen anderen Server bleibt „Manueller Server“ mit Adresse und Token.
Nicht geprüft: Gegen einen echten eigenen Forgejo von Iris (auf diesem Mac steht in
forgejo-admin.jsondie Adressehttp://forgejo:3300, die von hier nicht erreichbar ist): die Anmeldung per Basic mit echtem Passwort, Git über HTTPS mit der CA, die Besitzer-Liste. Außerdem weiterhin nicht: Installation aus dem Marktplatz in einer echten Iris, das Fenster im echten Plugin-Manager, ein Chat-Durchlauf mit Hermes, Linux.Grenzen: Die Anmeldung des eigenen Forgejo ist die des Administrators.
Offen: Echtlauf mit dem erreichbaren eigenen Forgejo, Installation und Chat-Durchlauf in der echten Iris, 6b (alf/2ndbrain#196).
status/zu-testenund das Schließen dieses Issues bleiben bei dir.PR #406 gemergt: feat(iris-rustapp-crafter): Modell als Dropdown mit Modelle abfragen, Besitzer-Fehler behoben, 0.1.2 (#388)
http://docker:3000/iris/iris-plugins/pulls/406
Commits:
Stand
Befund: Alf wünschte im Einstellungsfenster bei einem OpenAI-kompatiblen Server das Modell per Dropdown (wie im Marker-Plugin, Screenshots verglichen). Das fehlte: „Modell“ war ein Textfeld. Beim Nachvollziehen von Alfs Screenshot im echten WebKit fiel außerdem ein Fehler bei „Besitzer der Repos“ auf. Version 0.1.2.
Geändert: Neuer Panel-Befehl
modelle(GET /v1/modelsdes Servers, Schlüssel als Bearer, sortiert, ohne Doppelte; die Abfrage nutzt jetzt auchtest);web/settings.html: Beilokalundbasis-urlDropdown mit Knopf „Modelle abfragen“, Statuszeile und „Anderes Modell …“ mit Textfeld, das gespeicherte Modell bleibt wählbar, auch wenn der Server es nicht nennt; die Liste wird beim Öffnen und bei Änderung von Provider, URL oder Schlüssel still abgefragt (kein roter Fehler), beim Claude-Konto bleibt das Textfeld; Besitzer-Fehler behoben; Anleitung, Store-Texte und Changelog;plugin.json(0.1.2, Befehlmodelle); neutests/fenster_vorschau.py(Entwicklung, nicht im Paket): liefert das Fenster mit dem echten Backend aus, damit sich das Fenster im WebKit von Playwright prüfen lässt;PLAN.mdundsession-kontext.md.Geprüft: 421 Tests grün (zuletzt in 295 Sekunden), darunter 22 neue. Backend (
ModelleTest): Namen sortiert, Body ersetzt die gespeicherte Konfiguration nur für die Abfrage, Schlüssel nur als Bearer und nie in der Antwort, nur bei lokalem Server oder Basis-URL, ohne und mit ungültiger URL, nicht erreichbar, 401 mit Hinweis zum Schlüssel, Antwort ohne Liste, unbrauchbare Einträge. Fenster (Node): Dropdown mit gespeichertem Modell, stille Meldung bei nicht abrufbarem Server, Fehlermeldung des Knopfs, der Knopf ist danach wieder bedienbar, Abfrage sendet kein Modell und keine leeren Geheimnisse, „Anderes Modell“ mit gespeichertem Textfeld, ausgewähltes Modell, Claude-Konto ohne Abfrage, Besitzer. Im echten Browser: Das Fenster mit dem echten Backend im WebKit von Playwright (die Engine von Iris' WKWebView): Beim Laden 4 Modelle automatisch abgefragt und das gespeicherte vorgewählt, Auswahl, „Anderes Modell …“ blendet das Textfeld ein, „Modelle abfragen“ behält einen von Hand eingetragenen Namen, Besitzer getippt wird gespeichert, Claude-Konto zeigt das Textfeld; keine Seitenfehler; Darstellung angesehen. Gegenproben: getippter Besitzer wird verworfen und gespeichertes Modell nicht mehr wählbar machen je Tests rot.Gefunden: Ohne Besitzer-Liste (Forgejo nicht erreichbar) und ohne gespeicherten Besitzer blieb die Auswahl auf „— auswählen —“, und der ins Nachbarfeld getippte Name wurde beim Speichern verworfen (
besitzerWertlas nur die Auswahl): genau der Zustand in Alfs Screenshot. Jetzt zählt der getippte Name auch bei „— auswählen —“, Tippen wählt „Anderes …“, und ohne Liste steht die Auswahl auf „Anderes …“. Meine Node-Tests hatten das nicht gezeigt; erst der Blick in einen echten Browser und Alfs Screenshot.Nicht geprüft: Das Fenster im echten Plugin-Manager von Iris; ein echter OpenAI-kompatibler Server (nur der Test-Server der Vorschau und der Fake); die Darstellung in Chromium (dort fehlt auf diesem Rechner die passende Playwright-Version; die Chrome-Erweiterung war nicht verbunden).
Grenzen: Beim Claude-Konto gibt es keine Modellliste (Claude Code bietet keine Abfrage); dort bleibt das Textfeld.
Offen: Veröffentlichung von 0.1.2 nach der Regel für Plugin-Versionen (Tests grün, Trockenlauf; der Stand folgt als Kommentar), Echtlauf mit Iris' eigenem Forgejo, Installation und Chat-Durchlauf in der echten Iris, 6b.
Stand: 0.1.2 veröffentlicht
Befund:
iris-rustapp-crafter0.1.2 ist in der Plugin-Registry veröffentlicht (nach deiner Regel für Plugin-Versionen: 421 Tests grün, Trockenlauf grün, Stand im Issue).Geprüft: Nach einem frischen Pull des Registry-Repos: Commit
plugins: iris-rustapp-crafter 0.1.2auforigin/main;index.jsonnennt Version 0.1.2 (Änderungstext vorhanden), die Versionsliste enthält 0.1.0, 0.1.1 und 0.1.2, undpackages/iris-rustapp-crafter/hat die Pakete.Was Nutzer bekommen: Bei einem lokalen Server oder einer eigenen Basis-URL wählst du das Modell aus einer Liste, die der Server meldet („Modelle abfragen“, beim Öffnen automatisch); „Anderes Modell …“ erlaubt den Namen von Hand. Außerdem wird der Besitzer der Repos gespeichert, auch wenn du ihn ins Feld „oder anderer“ tippst (Fehler aus Alfs Screenshot).
Nicht geprüft: Das Fenster im echten Plugin-Manager von Iris (im Browser nur im WebKit von Playwright mit dem echten Backend geprüft), ein echter OpenAI-kompatibler Server, Chromium; weiterhin: Echtlauf mit Iris' eigenem Forgejo (hier nicht erreichbar), Installation aus dem Marktplatz in einer echten Iris, Chat-Durchlauf mit Hermes, Linux.
Offen: Echtlauf mit dem eigenen Forgejo, Installation und Chat-Durchlauf in der echten Iris, 6b (alf/2ndbrain#196).
status/zu-testenund das Schließen dieses Issues bleiben bei dir.PR #407 gemergt: feat(iris-rustapp-crafter): eigener Forgejo probiert Adressen, trennt Zustände (0.1.3) (#388)
http://docker:3000/iris/iris-plugins/pulls/407
Commits:
Stand: 0.1.3 – Iris' eigener Forgejo (Mac Studio)
Befund: Auf Alfs Mac Studio zeigte das Fenster „nicht erreichbar“. Lesend geprüft: Der Forgejo läuft auf 127.0.0.1:3300;
forgejo-admin.jsonnennthttp://forgejo:3300(nicht auflösbar) und Zugangsdaten, die dieser Forgejo mit 401 ablehnt.Geändert: Das Plugin probiert die Adresse aus den Zugangsdaten, die
ROOT_URLausapp.iniund die Standardadresse (Port 3300) und nutzt die, die antwortet. Das Fenster trennt „erreichbar“, „erreichbar, Anmeldung abgelehnt“ und „nicht erreichbar“, erklärt jeweils den Ausweg und wählt den eigenen Forgejo nur vor, wenn die Anmeldung gilt oder er gespeichert ist. Bei 401 meldet die Fehlermeldung die Adresse, nie das Passwort. Ein mit alter Adresse angelegtesoriginwird beim Einreichen auf die gefundene umgestellt. Version 0.1.3, Doku, Changelog, PLAN.md (8e) nachgezogen.Geprüft: 439 Tests (Fake-Forgejo, Adress-Kandidaten, Zustände, Zwischenspeicher,
remote_angleichen, Panel-Status, Fenster-Zustände im Node-Harness),publish-plugins.sh --dry-rungrün.Nicht geprüft: Gegen einen echten eigenen Forgejo mit gültiger Anmeldung; das Fenster im echten Plugin-Manager von Iris.
Grenzen: Die abgelehnten Zugangsdaten kann das Plugin nicht reparieren (Iris schreibt
forgejo-admin.json). Nutzbar ist dort ein manueller Server mit Token.iris-plugin-devhat vermutlich dieselbe Schwäche (nicht angefasst).Offen: Echtlauf mit Iris' eigenem Forgejo, Installation und Chat-Durchlauf in der echten Iris, 6b (alf/2ndbrain#196), Linux.
Veröffentlicht:
iris-rustapp-crafter0.1.3 liegt in der Registry (Paketiris-rustapp-crafter-0.1.3.irispluginnach dem Pull geprüft). Nutzer bekommen: Iris' eigener Forgejo wird über mehrere Adressen gefunden, das Fenster trennt erreichbar / Anmeldung abgelehnt / nicht erreichbar. Offen: Auf Alfs Mac Studio lehnt der Forgejo (127.0.0.1:3300) die Zugangsdaten ausforgejo-admin.jsonab (401) – dort hilft ein manueller Server mit Token; Echtlauf mit gültiger Anmeldung steht aus.PR #408 gemergt: feat(iris-rustapp-crafter): Figcraft aus der Paket-Registry installieren, CLI-Suche (0.2.0) (#388)
http://docker:3000/iris/iris-plugins/pulls/408
Commits:
Stand: 0.2.0 – Figcraft installieren (6b) und CLI-Suche
Befund: Das Fenster meldete „figcraft-cli nicht gefunden“, obwohl es in
~/.local/binliegt: Die Iris-App startet das Plugin mit knappem Suchpfad. Eine Installation aus der Registry gab es noch nicht.Geändert: (1)
figcraft_cli_pfadsucht zuletzt auch~/.local/bin,/opt/homebrew/bin,/usr/local/bin. (2) Neues Modulrc_figcraft_install.pyund Panel-Befehlefigcraft-version,figcraft-install, erweitertesfigcraft-status: Das Plugin lädtfigcraft-cliundFigCraft.appaus dem Generic-Packageiris/figcraft(angelegt vonpull-3rd-party, alf/2ndbrain#196, PR #197), prüft die SHA-256-Summen, und ersetzt erst danach: CLI in den Plugin-Ordner, App nach/Applications(laufende App unberührt, Kopierfehler lässt die alte stehen, nicht beschreibbar → Hinweis). Fenster: Knopf installieren/neu installieren/aktualisieren mit Versionshinweis. Panel-Timeout 300 s. Doku, Changelog, PLAN (6b) nachgezogen.Geprüft: 461 Tests grün (12 neue gegen lokalen Paketserver, Panel, Fenster; Gegenprobe Summenprüfung ausgebaut → rot); Echtlauf gegen die echte Registry in Wegwerf-Ordnern: CLI 0.17.1 läuft, Signatur gültig, kein Quarantäne-Attribut;
--dry-rungrün.Nicht geprüft: Start der installierten App auf einem frischen Mac (nicht notarisiert, Gatekeeper); Installation ins echte
/Applications; das Fenster im Plugin-Manager von Iris; Linux (Container folgt).Offen: Hermes-Eintrag
figcraft-crafternur auf Alfs Wort; Echtlauf mit Iris' eigenem Forgejo; Chat-Durchlauf in der echten Iris.Veröffentlicht:
iris-rustapp-crafter0.2.0 liegt in der Registry (Paketiris-rustapp-crafter-0.2.0.irispluginnach dem Pull geprüft). Nutzer bekommen: „Figcraft installieren/aktualisieren“ im Einstellungsfenster (CLI und App aus der Paket-Registry, mit Prüfsumme) und die Suche des figcraft-cli auch in ~/.local/bin, Homebrew und /usr/local/bin. Offen: Start der installierten, nicht notarisierten App auf einem frischen Mac; Installation ins echte /Applications; Linux.PR #409 gemergt: fix(iris-rustapp-crafter): Statuszeile zeigt auch FigCraft.app (0.2.1) (#388)
http://docker:3000/iris/iris-plugins/pulls/409
Commits:
Stand: 0.2.1 – Figcraft-Zeile zeigt auch die App
Befund: Nach „Figcraft installieren“ meldete das Fenster „App: /Applications/FigCraft.app“, die Statuszeile oben nannte aber nur das figcraft-cli; es sah aus, als sei nur das CLI installiert. Nachgesehen:
/Applications/FigCraft.appliegt da (0.17.1, Signatur gültig, kein Quarantäne-Attribut, keine.alt-Reste).Geändert: Die Statuszeile zeigt zusätzlich, ob FigCraft.app im Programme-Ordner liegt (
app_vorhanden). Version 0.2.1, Changelog (Manifest auf unter 1000 Zeichen gekürzt).Geprüft: Fenster-, Paket- und Panel-Tests grün (Fenster mit und ohne App),
--dry-rungrün; die App im echten/Applicationspercodesign --verifyundxattr.Nicht geprüft: Volle Suite (nur die drei betroffenen Dateien); Start der App auf einem frischen Mac (Gatekeeper); das Fenster im Plugin-Manager nach dem Update.
Offen: wie in 0.2.0.
Veröffentlicht:
iris-rustapp-crafter0.2.1 liegt in der Registry (nach dem Pull geprüft). Nutzer sehen in der Figcraft-Zeile jetzt auch, ob FigCraft.app im Programme-Ordner liegt. Offen: wie in 0.2.0.PR #410 gemergt: fix(iris-rustapp-crafter): config-status meldet configured, save trägt den eigenen Forgejo (0.2.2) (#388)
http://docker:3000/iris/iris-plugins/pulls/410
Commits:
Stand: 0.2.2 – config-status-Vertrag, Zustand nach „Speichern“
Befund (Alfs Screenshots): (1) Nach „Speichern“ sprang der Forgejo-Server im Fenster auf „nicht auf diesem Rechner gefunden“ und der manuelle Server war gewählt. (2) Die Plugin-Kachel war rot: „Ungültige Antwort des Plugins: Zustand "ready" ist weder 'configured' noch …“.
Ursache: (1) Die Antwort von
savehatte keinen Blockeigener; das Fenster zeichnet sich aus dieser Antwort neu. (2)config-statusmeldete seit 0.1.0readystattconfigured(README 21.5); die Tests prüften den falschen Wert, solange das Plugin gelb war (needs_configuration) fiel es nicht auf.Geändert:
config-statusmeldetconfigured;saveantwortet miteigenerwiestatus; das Fenster behält den bisherigen Zustand, wenn eine Antwort den Block nicht trägt. Neue Tests:config-statusnur aus der erlaubten Menge des Vertrags,saveträgt den Zustand, Fenster nach „Speichern“ (Gegenprobe ohne Fix rot). Version 0.2.2, Changelog, Lessons Learned in PLAN.md.Geprüft: 464 Tests grün,
--dry-rungrün.Nicht geprüft: Die Kachel im Plugin-Manager von Iris nach dem Update (Farbe grün); das Fenster im Plugin-Manager nach „Speichern“.
Offen: wie in 0.2.0.
Veröffentlicht:
iris-rustapp-crafter0.2.2 liegt in der Registry (nach dem Pull geprüft). Nutzer bekommen: Die Kachel im Plugin-Manager ist nach der Einrichtung grün (config-status meldete einen ungültigen Zustand), und „Speichern“ lässt den eigenen Forgejo im Fenster nicht mehr auf „nicht gefunden“ springen. Offen: wie in 0.2.0.PR #411 gemergt: feat(iris-rustapp-crafter): Entwurf in FigCraft öffnen statt selbst begutachten (0.3.0) (#388)
http://docker:3000/iris/iris-plugins/pulls/411
Commits:
Stand: 0.3.0 – Entwurf in FigCraft öffnen statt selbst begutachten
Befund (erster Chat-Durchlauf, Chat-Export): Nach
gui exportschickte Hermes ein PNG anvision_analyze. Die Anfrage lief auf dem Strata-Server (ein Slot, GPU 0 bei 99 %) ohne Ende; der Client brach nach 120 s ab, die Anfrage blieb auf dem Server, der nächste Modellaufruf bekam 900 s keine Bytes („Stream stale“). Plugin und Zustand waren in Ordnung (Beschreibung freigegeben, Vorlage und Export vorhanden). Alfs Wunsch: Das Modell soll den Entwurf nicht begutachten, sondern FigCraft damit öffnen, damit er Anweisungen geben oder selbst ändern kann.Geändert: Neuer Befehl
gui oeffnen(rc_gui.oeffnen,figcraft_app_pfad:RUSTAPP_CRAFTER_FIGCRAFT_APP, Programme-Ordner,~/Applications, Schreibtisch;open -a). SKILL.md: nachgui vorlagesofort öffnen, keine Bildanalyse, auf den Nutzer warten; Änderungswünsche per MCPfigcraft-crafter(falls eingetragen) und erneut öffnen; nach „gespeichert“gui exportundgui pruefen. Doku, Changelog, PLAN (6d). Version 0.3.0.Geprüft: 469 Tests grün (5 neue); echter Aufruf: FigCraft startet aus /Applications mit der Entwurfsdatei;
--dry-rungrün.Nicht geprüft:
openaus dem Hermes-Gateway-Prozess (Fenster-Sitzung); ob Änderungen, die Iris per headless MCP in die Datei schreibt, in einer schon geöffneten FigCraft-Instanz erscheinen (vermutlich nicht); der Chat-Durchlauf mit dem neuen Skill; der hängende Strata-Server (nicht Teil des Plugins).Offen: Hermes-Eintrag
figcraft-crafter(nur auf Alfs Wort); Live-Steuerung der offenen App (MCP der App statt headless); Rest wie in 0.2.0.Veröffentlicht:
iris-rustapp-crafter0.3.0 liegt in der Registry (nach dem Pull geprüft). Nutzer bekommen: Iris öffnet den GUI-Entwurf in FigCraft (gui oeffnen), statt ihn per Bildanalyse selbst zu begutachten. Offen: wie im Stand-Kommentar (Gateway-Fenstersitzung, Live-Steuerung der offenen App).PR #412 gemergt: feat(iris-rustapp-crafter): Hermes arbeitet live im offenen FigCraft per MCP (0.4.0) (#388)
http://docker:3000/iris/iris-plugins/pulls/412
Commits:
Stand: 0.4.0 – Hermes arbeitet live im offenen FigCraft
Befund (Alfs „Speichern“ ging nicht): Hermes schrieb die Entwurfsdatei um 21:07 per
figcraft-clian der offenen App vorbei. FigCraft verweigert das Speichern, wenn eine andere App die Datei seit dem Öffnen geändert hat (FigCraft-Quelle zufile.save); Alf speicherte unter neuem Namen auf den Desktop, Iris suchte am falschen Ort. Alfs Erwartung: Hermes spricht über den MCP-Server mit dem geöffneten FigCraft, und „Speichern“ schreibt die Originaldatei.Geändert:
gui oeffnenstartet FigCraft mit--control PORT(7979) und aufWorkspacesbegrenztem Dateizugriff, öffnet bei laufendem Kanal nur die Datei, verweigert mit Anleitung (Cmd+Q), wenn FigCraft ohne Kanal läuft (nichts wird beendet). Hermes-Eintragfigcraft-app=figcraft-cli mcp --attach PORT(figcraft hermes-registrieren, ohne--wurzel, entfernt den früheren Namen mit). SKILL.md: Änderungen live überfigcraft-app, die Datei nie anders schreiben. Doku, Changelog, PLAN (6e). Version 0.4.0.Geprüft: 474 Tests grün; Echtlauf der Kette: Start mit Steuerkanal (offen nach 1 s),
inspect_documentzeigt das Dokument mit Pfad,create_node(Stempel) live,save_filein die Originaldatei (44 Knoten, Stempel auf der Platte);--dry-rungrün.Nicht geprüft: Der Eintrag in der echten Hermes-Konfiguration (nur auf Alfs Wort), Neustart des Gateways;
open -naus dem Hermes-Gateway-Prozess; ob ein lokales Modell mit dem großen Werkzeugangebot der angehängten App zurechtkommt; Alfs UI-„Speichern“ nach Live-Änderungen (nursave_fileper MCP getestet).Offen: Alfs laufende FigCraft-Instanz läuft ohne Kanal und muss einmal beendet werden. Rest wie in 0.2.0.
Veröffentlicht:
iris-rustapp-crafter0.4.0 liegt in der Registry (nach dem Pull geprüft). Nutzer bekommen:gui oeffnenstartet FigCraft mit Steuerkanal; der Hermes-Eintragfigcraft-app(figcraft hermes-registrieren) hängt sich per MCP an die laufende App, Iris ändert live und du speicherst in die Originaldatei. Offen: wie im Stand-Kommentar (Registrierung in Hermes nur auf Alfs Wort, Gateway-Fenstersitzung, lokales Modell mit dem Werkzeugangebot).PR #413 gemergt: fix(iris-rustapp-crafter): Neustart trifft das Gateway, nicht die Weboberfläche (0.4.1) (#388)
http://docker:3000/iris/iris-plugins/pulls/413
Commits:
Stand: 0.4.1 – richtiges Gateway beim Neustart
Befund:
figcraft hermes-registrieren --neustartenkickstartetecom.nousresearch.hermes-serve. Das ist die Hermes-Weboberfläche (hermes serve, Port 9119). Das Gateway, das die MCP-Werkzeuge lädt, istai.hermes.gateway(Port 8642; perlaunchctl list, Plist undlsofnachgesehen). Das Label war ausiris-solidcraftübernommen, ohne es zu prüfen (dort derselbe Fehler, nicht angefasst).Geändert:
GATEWAY_LABEL = "ai.hermes.gateway"; Test prüft das Label und dass „hermes-serve“ nicht vorkommt; Lessons Learned in PLAN.md; Version 0.4.1.Geprüft:
test_mcpundtest_paketgrün,--dry-rungrün. Nicht geprüft: Volle Suite (Änderung ist eine Konstante); ein echter Neustart des Gateways (nur auf Alfs Wort).Offen:
iris-solidcrafthat denselben falschen Label (panel_api.py:72); Rest wie in 0.4.0.Veröffentlicht:
iris-rustapp-crafter0.4.1 liegt in der Registry (nach dem Pull geprüft):figcraft hermes-registrieren --neustartenstartet jetzt das Gateway (ai.hermes.gateway) neu, nicht die Hermes-Weboberfläche. Offen:iris-solidcrafthat denselben falschen Label (panel_api.py:72).PR #414 gemergt: feat(iris-rustapp-crafter): Claude-Code-Jobs erscheinen im Reiter Hintergrundjobs (0.5.0) (#388)
http://docker:3000/iris/iris-plugins/pulls/414
Commits:
Stand: 0.5.0 – Claude-Code-Jobs im Reiter „Hintergrundjobs“
Anlass (Alf, erster Durchlauf): Beim Start des Claude-Code-Agenten soll der Lauf im Seitenpanel unter „Hintergrundjobs“ (Plugin
iris-jobs) erscheinen; bisher stand dort „In diesem Chat läuft kein Hintergrundjob“.Geändert:
rc_claude.startenmeldet den Job über den geteilten Reporteriris-async-reporter.pyan (im_reiter_anmelden): nur wenn der Aufruf in einem Chat läuft (HERMES_SESSION_ID) und der Reporter vorliegt; Fehler hier stören den Job nie. Name im Reiter: „: “ (bei Nachbesserung mit Zusatz).job poll(STATUS/LOG im Vertrag des Reporters; Zustände wartet/läuft → running, fertig → done, abgebrochen → cancelled, alles andere → failed) undjob deliver(OK: …). „Abbrechen“ im Reiter ruftjob abbrechen.--quiet(neu, optional, in_shared/iris-async-reporter): nur das Register, keine Meldung in den Chat, keine Systemmeldung, kein Push an gekoppelte Geräte (sonst gäbe es je Bauschritt ein „🎵 … fertig“). Rückwärtskompatibel, Test mit Gegenprobe.Geprüft: 481 Tests grün; neu: Anmeldung mit Fake-Reporter (Argumente, Befehle, ohne Chat/ohne Reporter läuft der Job trotzdem),
job poll/deliverfür alle Zustände, ganzer Weg mit dem echten Reporter: Eintrag im Register,iris-jobs(jobs_core) liest ihn unter „Dieser Chat“, Status „done“; Abbrechen aus dem Reiter beendet den Läufer („abgebrochen“); Reporter-Test, dass--quietnichts an Iris sendet (Gegenprobe: ohne die Zeile rot).--dry-rungrün, Paket enthält den Reporter.Nicht geprüft: Der Reiter selbst in Iris mit einem echten Lauf (Aussehen, „Dieser Chat“-Filter mit der echten Chat-ID); ob
HERMES_SESSION_IDim Terminal-Werkzeug von Hermes bei jedem Aufruf gesetzt ist (Hermes nutzt es für andere Plugins; nicht für diesen Lauf nachgesehen). Der laufende Job startete vor diesem Stand und erscheint nicht.Offen / entdeckt: Der erste Claude-Code-Lauf zeigte, dass der Auftrag nicht sagt, woher
panel-kitkommt (eigenes Repoiris/panel-kit, nicht auf crates.io; Claude Code ließ die Abhängigkeit weg). Das ist die offene Frage „Projektgerüst“ aus dem Plan (Quelle als Pfad oder Git,--add-dirzum Lesen); Entscheidung bei Alf. Rest wie in 0.2.0.Veröffentlicht:
iris-rustapp-crafter0.5.0 liegt in der Registry (nach dem Pull geprüft). Nutzer bekommen: Claude-Code-Läufe erscheinen im Seitenpanel unter „Hintergrundjobs“ (Dieser Chat / Alle) mit Laufzeit, Status, Ergebnis und „Abbrechen“; der Reporter meldet ruhig (--quiet, neu im geteilten Reporter): keine Chat-Meldung, keine Systemmeldung, kein Push. Offen: Quelle vonpanel-kitim Auftrag (Pfad oder Git, Entscheidung bei Alf); der Reiter mit einem echten Lauf in Iris.PR #415 gemergt: feat(iris-rustapp-crafter): Cargo-Eintrag für panel-kit fest im Auftrag, Lesezugriff ohne Schreibrecht (0.6.0) (#388)
http://docker:3000/iris/iris-plugins/pulls/415
Commits:
Stand: 0.6.0 – Projektgerüst: Quelle von
panel-kitfest im AuftragBefund (erster Claude-Code-Lauf, Alfs Session-Ansicht): Der Auftrag sagte nur „panel-kit als Abhängigkeit“.
panel-kitliegt nicht auf crates.io (eigenes Repoiris/panel-kit); Claude Code ließ es ehrlich weg und meldete das. Für Schritt s1 (Datenbank, Repository-Schicht) folgenlos, für s2/s3 (Panels) nicht. Das war die offene Frage „Projektgerüst“ aus dem Plan.Entscheidung (Alf): Den Cargo-Eintrag fest in den Auftrag schreiben (lokaler Pfad, Git als Rückfall).
Geändert:
rc_projektgeruest.py(neu): lokaler Checkout als Pfad (RUSTAPP_CRAFTER_PANEL_KIT, Vorgabe~/Documents/2ndbrain/frontend/panel-kit), sonst Githttp://docker:3000/iris/panel-kit.git(RUSTAPP_CRAFTER_PANEL_KIT_GIT).auftrag_text: Abschnitt „Projektgerüst (festgelegt)“ mit dem Cargo-Eintrag, Leptos 0.8 csr, Anwenderdokumentation unddemo/als Vorbild; bei Pfad--add-dirfür Claude Code und--disallowedTools Edit(//…/**), Write(//…/**)(ohne die Sperre gäbe--add-dirauch Schreibrechte).job.jsonmerkt sichlesepfade.pruefen: Ein Schritt mit Panelarten ist rot, wennpanel-kitin keinerCargo.tomlsteht (ohnetarget/,.git/,.crafter/).Geprüft: 494 Tests grün (11 neue für Quelle/Abschnitt/Argumente/Erkennung, 2 neue Schleifen-Tests; Gegenprobe Wächter ausgebaut → rot). Echtlauf mit dem echten Claude Code auf einer Kopie des Ordners: Lesen erlaubt, Schreiben in den Ordner verweigert (Datei existiert nicht), Schreiben im Arbeitsordner erlaubt; Gegenprobe ohne Sperrregel: Claude schreibt in den Ordner.
--dry-rungrün.Nicht geprüft: Ein kompletter Lauf eines Schritts mit Panelarten gegen das echte
panel-kit(ob das lokale Modell die Demo richtig nachbaut); die Git-Variante (Cargo holt ausdocker:3000: Zugriff, Netz);trunkim Lauf. Der laufende Job s1 startete vor diesem Stand und kennt den Eintrag nicht.Offen: Das Gerüst der App (Kopie der Demo,
index.html,Trunk.toml; Tauri oder nur Browser) bleibt Sache der Schritte und ist weiter nicht entschieden. Rest wie in 0.2.0.Veröffentlicht:
iris-rustapp-crafter0.6.0 liegt in der Registry (nach dem Pull geprüft). Nutzer bekommen: Jeder Auftrag an Claude Code enthält den festen Cargo-Eintrag fürpanel-kit(lokaler Checkout als Pfad, sonst Git); Claude Code darf den Checkout lesen, aber nicht ändern (mit dem echten Claude Code geprüft); ein Schritt mit Panelarten fällt durch, wennpanel-kitin keinerCargo.tomlsteht. Offen: ein kompletter Schritt mit Panelarten gegen das echtepanel-kit; die Git-Variante; das App-Gerüst (Demo-Kopie, Trunk, Tauri oder Browser).