iris/iris-plugins
1
0
Fork 0
Code Issues 17 Pull requests Projects Releases Packages Wiki Activity Actions

iris-plugin-dev: _klone/Arbeitsordner verwirrt, Plan nicht änderbar, Systemprompt fehlt im grill-me (Erfahrungen aus #167) #171

New issue
Closed
opened 2026-10-21 16:38:29 +00:00 by alf · 12 comments
alf commented 2026-10-21 16:38:29 +00:00
Owner
Copy link

Stand: Etappe 1 (Arbeitsordner und Klone, PR #174), Etappe 2 (Systemprompt, PR #176) und Etappe 4 (Panel-Anmeldeprüfung, PR #177) sind gemergt, aber noch nicht veröffentlicht (Version 0.1.3). Offen: 3 paket, 5 plan aendern und die kleineren Punkte. Der Verlauf steht in den Kommentaren.

Anlass

Beim Bau des Plugins iris-claude-sessions (#167) mit dem Plugin iris-plugin-dev ("Plugins entwickeln") sind mehrere Stellen aufgefallen, an denen das Werkzeug verwirrt oder zu spät etwas fordert. Das Verwirrendste: der _klone-Ordner. Dieses Issue sammelt den Befund, die Erfahrungen aus dem Lauf und Verbesserungsvorschläge. Der Lauf selbst hat die Stufen sauber durchlaufen (grill-me → Plan → Gerüst → Repo → Umsetzung → pruefen), und die Sperren haben funktioniert: Das Veröffentlichen blieb bis zum Praxistest zu.

1. Befund: _klone und der Arbeitsordner (Hauptproblem)

  • neu legt das Vorhaben unter ./plugin-dev relativ zum aktuellen Verzeichnis an. Der Aufruf kam aus dem Repo der Iris-App (frontend/macos-iris) und legte dort einen untracked Ordner plugin-dev/ an; ein späteres ship -a hätte ihn mitgenommen. Erst --home oder $PLUGIN_DEV_HOME ändert das, die Doku nennt es aber nur nebenbei.
  • repo anlegen verschiebt das Vorhaben in einen Klon <home>/_klone/iris-plugins/<id> und lässt im alten Ordner nur .dev/umzug.json als Marker liegen. Danach existieren zwei Orte mit demselben Namen, einer davon fast leer. Wer in den alten Ordner schaut, sieht kein Plugin, keine PLAN.md, keinen Code.
  • Ist --home der Checkout des Plugin-Repos selbst (~/Documents/2ndbrain/plugins, so wie bei allen anderen Plugins üblich), liegt _klone/ mitten im Repo als untracked Ordner, und das Plugin steht nicht unter plugins/<id>/ neben den anderen. Der Modul-Kommentar sagt "Arbeitet nur gegen Forgejo ... nie gegen ein lokales Checkout"; für diesen Fall ist das genau der Widerspruch zur Konvention "jedes Plugin lebt in plugins/<id>/".
  • Folge im Alltag: Der Nutzer fand die PLAN.md nicht (sie lag im Klon, der Branch war nicht gemergt) und hielt den Ordner für ein Versehen. Ich habe _klone/ lokal in .git/info/exclude eingetragen und den leeren Alt-Ordner von Hand gelöscht.
  • Der Checkout stand außerdem auf einem fremden Branch (165-iris-solidcraft), den man nicht umschalten darf. Ein Klon ist dafür richtig, ein git worktree wäre es auch.

Vorschläge

  1. Arbeitsordner nie relativ zum cwd. Standard fest (~/Library/Application Support/Iris/plugin-dev bzw. ~/.local/share/iris-plugin-dev), nie in einem Git-Repo. neu bricht ab, wenn das Ziel innerhalb eines anderen Git-Repos läge, und sagt es.
  2. Klone außerhalb jedes Repos (derselbe feste Ordner, <home>/klone/<repo>/<id>), nicht unter plugins/.
  3. Immer sagen, wo das Plugin liegt. status und die Ausgabe von repo anlegen nennen den vollständigen Pfad in einer Zeile, außerdem ein Befehl pfad (nur den Pfad ausgeben, für Skripte).
  4. Marker .dev/umzug.json nicht als Geisterordner stehen lassen: den alten Ordner nach dem Umzug entfernen, wenn er nichts außer dem Marker enthält, und der Marker liegt im festen Arbeitsordner (vorhaben/<id>.json).
  5. Optional: Modus "im Checkout arbeiten" (--im-checkout <pfad>): legt per git worktree einen Branch NN-<id> im vorhandenen Checkout an, sodass das Plugin unter plugins/<id>/ liegt, ohne den ausgecheckten Branch zu berühren.

2. Befund: Plan nach der Freigabe nicht mehr änderbar

  • Nach "Plan passt" ist plan setzen gesperrt, und die Freigabe ist an den Fingerabdruck von .dev/plan.json gebunden. Im Betrieb hat sich der Plan aber geändert: ein Systemprompt kam dazu (Abschnitt 3), das Canvas wurde umgebaut, der Terminal-Start bekam eine App-Route. Eine Änderung in plan.json hätte die Freigabe verworfen und das Vorhaben auf Stufe 3 zurückgeworfen.
  • Die erzeugte PLAN.md trägt den Hinweis "Änderungen in plan.json machen", was nach der Freigabe nicht geht. Ich habe stattdessen einen Abschnitt "Stand und Abweichungen" an die PLAN.md angehängt (Fingerabdruck blieb stabil). Das ist ein Ausweg, kein Verfahren.
  • Das Plan-Format hat ein Feld systemprompt (Standard false), aber PLAN.md zeigt es nicht, der Verwendungssatz fehlte, und die Konsistenzprüfung verglich es nicht mit dem Manifest (so korrigiert nach dem Lesen des Codes, siehe Kommentar zu Etappe 2).

Vorschläge

  1. Befehl plan aendern --grund "…" nach der Freigabe: erlaubt eine Änderung an plan.json, hängt einen Eintrag in ein Änderungsprotokoll (.dev/aenderungen.json, erscheint in PLAN.md) und verlangt nur für die geänderten Felder erneut "Plan passt".
  2. Feld systemprompt (und Name/Verwendung) in plan.json aufnehmen und in PLAN.md rendern.
  3. Hinweis in PLAN.md je nach Stufe: vor der Freigabe "Änderungen in plan.json", danach "Änderungen siehe Änderungsprotokoll".

3. Befund: grill-me fragt nicht nach dem Iris-Systemprompt (größte inhaltliche Lücke)

Das Plugin hatte laut Plan systemprompt: false. Folge im Praxistest: Der Auto-Modus der App wählte nur "Canvas System" (die Anfrage enthielt "im Canvas"), Hermes lud den Skill nie, las einen 37-KB-Canvas-Skill und schrieb ein Eigenbau-Skript (zufällig mit demselben Namen claude_sessions.py). Erst ein eigener Systemprompt mit usage ("Claude Code Chats verwalten …") löste das. Das hat vier Testrunden gekostet.

Vorschläge

  1. Neues Pflichtthema im grill-me: "Systemprompt und Auto-Modus", mit der Empfehlung "ja" für jedes Plugin, das per Chat oder Canvas bedient wird, und "nein" nur bei reinen Hintergrund-Plugins. Das Thema fragt nach der usage-Formulierung (sie entscheidet über die Auto-Auswahl) und nach Nachbar-Prompts, gegen die es sich abgrenzen muss ("Canvas System", iris-gui, claude-code).
  2. Das Gerüst erzeugt system_prompt.md und die Manifest-Felder (system_prompt, system_prompt_name, system_prompt_usage), wenn das Thema "ja" ergibt, mit einem Baustein für die Aufrufe, die das Modell wörtlich übernehmen soll.
  3. pruefen prüft die Konsistenz: Manifest-Felder und system_prompt.md müssen zusammenpassen, der Skill-Name muss im Prompt vorkommen, die usage darf nicht leer sein.

4. Befund: Praxistest ist nur über die Registry vorgesehen, Testverteilung fehlt

  • veroeffentlichen ist erst nach "Praxistest bestanden" erlaubt, der Test setzt aber ein installiertes Plugin voraus. Mein Weg: build-irisplugin.sh mit OUTPUT_DIR, dann scp auf den zweiten Rechner und dort per GUI importieren. Der Skill kennt diesen Weg nicht, pruefen baut das Paket nur zur Probe und wirft es weg.
  • Pro Test-Runde musste ich version in plugin.json von Hand hochzählen (0.1.0 bis 0.1.8), damit der Import ersetzt.

Vorschläge

  1. Befehl paket: baut <id>-<version>.irisplugin (Standard ~/Desktop) und zählt auf Wunsch (--patch) die Version hoch.
  2. Befehl paket --nach <host>: kopiert das Paket per scp auf einen in der Konfiguration genannten Testrechner.
  3. In die Doku (bauen): "Test auf einem zweiten Rechner" mit genau diesem Ablauf, einschließlich der Prüfung, ob die laufende App neuer ist als die Route/Funktion, die das Plugin braucht (hier: HTTP 401, weil die App vom Vortag stammte). Ein Befehl pruefen --app könnte die gebaute App nach den erwarteten Routen durchsuchen.

5. Befund: Panel "Verbindung testen" liefert 403 trotz richtigem Token

Der Test fragt GET /api/v1/user ab (braucht den Scope read:user), die Anleitung im Panel empfiehlt aber nur Repository- und Issue-Schreibrecht. Ein so angelegtes Token bekommt 403, obwohl es für Issues, Branches und PRs reicht.

Vorschläge

  1. Als Anmeldeprüfung GET /api/v1/repos/<repo> verwenden (liefert permissions.push), /user entfällt.
  2. Die Antwort von Forgejo (message) im Detail mitzeigen statt nur "antwortet 403".
  3. In der Anleitung den Scope benennen, falls read:user doch gebraucht wird.

6. Kleinere Stolpersteine

  • Globale Optionen stehen vor dem Unterbefehl: plugin_dev.py status --vorhaben <id> scheitert mit "unrecognized arguments"; richtig ist --home … --vorhaben … status. Die SKILL.md zeigt es nicht eindeutig. Vorschlag: Optionen auch nach dem Unterbefehl akzeptieren.
  • PD="python3 -I …" aus der SKILL.md funktioniert in zsh nicht ($PD wird nicht in Wörter zerlegt, "no such file or directory"). Vorschlag: ein kleines Wrapper-Skript plugin-dev statt einer Variablen, oder ${=PD} dokumentieren.
  • Skills müssen ohne execute_code auskommen: auf dem api_server (unattended) wird es blockiert, das Modell wich auf das terminal-Werkzeug aus. Die Skill-Vorlage und die Doku sollten das sagen ("nur terminal, kein execute_code").
  • Nach einem Klick im Canvas improvisiert das Modell: Es meldete einmal "umbenannt", ohne das Skript zu rufen (Request-Dump ~/.hermes/sessions/request_dump_*.json zeigte das). Skripte sollten tolerant sein und den Aufruf im Prompt wörtlich nennen (hier gelöst). Das ist ein Hinweis für die Skill-Vorlage; eine strukturelle Lösung wäre ein App-seitiger Klick-Handler (eigenes Thema, nicht hier).
  • repo senden erinnert nicht an Versionsnummer und PLAN.md: Eine Prüfung "Version seit dem letzten Paket gleich geblieben?" wäre hilfreich.
  • Beim Gerüst fehlt ein Canvas-Baustein: Für Plugins mit Canvas wären ein canvas-Befehl, ein auswahl-Befehl (Rückmeldung auswerten) und die Tests dazu als Vorlage hilfreich. Diese beiden Befehle waren die Kernstücke von iris-claude-sessions.

7. Was gut funktioniert hat (beibehalten)

  • grill-me mit einer Frage zur Zeit und einer Empfehlung je Thema; "Grill-me fertig" und "Plan passt" bleiben beim Nutzer.
  • Die Sperren pro Stufe (kein Veröffentlichen ohne Praxistest) und das Protokoll der Freigaben mit Wortlaut.
  • pruefen (TODO-Marker, Tests, Manifest, Paketbau) in einem Schritt und stand-kommentar ins Issue.
  • repo anlegen legt Issue, Branch und PR sauber an und merged nie von selbst.

Vorschlag für die Reihenfolge

  1. Arbeitsordner und Klone fest und außerhalb von Repos (Abschnitt 1, Punkte 1 bis 4), weil das den Nutzer am meisten verwirrt.
  2. grill-me-Thema "Systemprompt" plus Gerüst und Prüfung (Abschnitt 3), weil es den größten Zeitverlust verursacht hat.
  3. paket und paket --nach (Abschnitt 4).
  4. Panel-Anmeldeprüfung (Abschnitt 5).
  5. plan aendern (Abschnitt 2) und die kleineren Punkte (Abschnitt 6).

Bezug: iris/iris-plugins#167 (iris-claude-sessions, Fundstelle), iris/iris-plugins#99 (Plan des Skills), iris/Iris#130 und iris/Iris#132 (Auslöser des Plugins).

> **Stand:** Etappe 1 (Arbeitsordner und Klone, PR #174), Etappe 2 (Systemprompt, PR #176) und Etappe 4 (Panel-Anmeldeprüfung, PR #177) sind gemergt, aber noch nicht veröffentlicht (Version 0.1.3). Offen: 3 `paket`, 5 `plan aendern` und die kleineren Punkte. Der Verlauf steht in den Kommentaren. ## Anlass Beim Bau des Plugins `iris-claude-sessions` (#167) mit dem Plugin `iris-plugin-dev` ("Plugins entwickeln") sind mehrere Stellen aufgefallen, an denen das Werkzeug verwirrt oder zu spät etwas fordert. Das Verwirrendste: **der `_klone`-Ordner**. Dieses Issue sammelt den Befund, die Erfahrungen aus dem Lauf und Verbesserungsvorschläge. Der Lauf selbst hat die Stufen sauber durchlaufen (grill-me → Plan → Gerüst → Repo → Umsetzung → `pruefen`), und die Sperren haben funktioniert: Das Veröffentlichen blieb bis zum Praxistest zu. ## 1. Befund: `_klone` und der Arbeitsordner (Hauptproblem) - **`neu` legt das Vorhaben unter `./plugin-dev` relativ zum aktuellen Verzeichnis an.** Der Aufruf kam aus dem Repo der Iris-App (`frontend/macos-iris`) und legte dort einen untracked Ordner `plugin-dev/` an; ein späteres `ship -a` hätte ihn mitgenommen. Erst `--home` oder `$PLUGIN_DEV_HOME` ändert das, die Doku nennt es aber nur nebenbei. - **`repo anlegen` verschiebt das Vorhaben in einen Klon** `<home>/_klone/iris-plugins/<id>` und lässt im alten Ordner nur `.dev/umzug.json` als Marker liegen. Danach existieren zwei Orte mit demselben Namen, einer davon fast leer. Wer in den alten Ordner schaut, sieht kein Plugin, keine `PLAN.md`, keinen Code. - **Ist `--home` der Checkout des Plugin-Repos selbst** (`~/Documents/2ndbrain/plugins`, so wie bei allen anderen Plugins üblich), liegt `_klone/` mitten im Repo als untracked Ordner, und das Plugin steht nicht unter `plugins/<id>/` neben den anderen. Der Modul-Kommentar sagt "Arbeitet nur gegen Forgejo ... nie gegen ein lokales Checkout"; für diesen Fall ist das genau der Widerspruch zur Konvention "jedes Plugin lebt in `plugins/<id>/`". - **Folge im Alltag:** Der Nutzer fand die `PLAN.md` nicht (sie lag im Klon, der Branch war nicht gemergt) und hielt den Ordner für ein Versehen. Ich habe `_klone/` lokal in `.git/info/exclude` eingetragen und den leeren Alt-Ordner von Hand gelöscht. - **Der Checkout stand außerdem auf einem fremden Branch** (`165-iris-solidcraft`), den man nicht umschalten darf. Ein Klon ist dafür richtig, ein `git worktree` wäre es auch. ### Vorschläge 1. **Arbeitsordner nie relativ zum cwd.** Standard fest (`~/Library/Application Support/Iris/plugin-dev` bzw. `~/.local/share/iris-plugin-dev`), nie in einem Git-Repo. `neu` bricht ab, wenn das Ziel innerhalb eines anderen Git-Repos läge, und sagt es. 2. **Klone außerhalb jedes Repos** (derselbe feste Ordner, `<home>/klone/<repo>/<id>`), nicht unter `plugins/`. 3. **Immer sagen, wo das Plugin liegt.** `status` und die Ausgabe von `repo anlegen` nennen den vollständigen Pfad in einer Zeile, außerdem ein Befehl `pfad` (nur den Pfad ausgeben, für Skripte). 4. **Marker `.dev/umzug.json` nicht als Geisterordner stehen lassen:** den alten Ordner nach dem Umzug entfernen, wenn er nichts außer dem Marker enthält, und der Marker liegt im festen Arbeitsordner (`vorhaben/<id>.json`). 5. **Optional: Modus "im Checkout arbeiten"** (`--im-checkout <pfad>`): legt per `git worktree` einen Branch `NN-<id>` im vorhandenen Checkout an, sodass das Plugin unter `plugins/<id>/` liegt, ohne den ausgecheckten Branch zu berühren. ## 2. Befund: Plan nach der Freigabe nicht mehr änderbar - Nach "Plan passt" ist `plan setzen` gesperrt, und die Freigabe ist an den Fingerabdruck von `.dev/plan.json` gebunden. Im Betrieb hat sich der Plan aber geändert: ein Systemprompt kam dazu (Abschnitt 3), das Canvas wurde umgebaut, der Terminal-Start bekam eine App-Route. Eine Änderung in `plan.json` hätte die Freigabe verworfen und das Vorhaben auf Stufe 3 zurückgeworfen. - Die erzeugte `PLAN.md` trägt den Hinweis "Änderungen in plan.json machen", was nach der Freigabe nicht geht. Ich habe stattdessen einen Abschnitt "Stand und Abweichungen" an die `PLAN.md` angehängt (Fingerabdruck blieb stabil). Das ist ein Ausweg, kein Verfahren. - Das Plan-Format hat ein Feld `systemprompt` (Standard `false`), aber `PLAN.md` zeigt es nicht, der Verwendungssatz fehlte, und die Konsistenzprüfung verglich es nicht mit dem Manifest (so korrigiert nach dem Lesen des Codes, siehe Kommentar zu Etappe 2). ### Vorschläge 1. Befehl **`plan aendern --grund "…"`** nach der Freigabe: erlaubt eine Änderung an `plan.json`, hängt einen Eintrag in ein Änderungsprotokoll (`.dev/aenderungen.json`, erscheint in `PLAN.md`) und verlangt nur für die **geänderten** Felder erneut "Plan passt". 2. Feld `systemprompt` (und Name/Verwendung) in `plan.json` aufnehmen und in `PLAN.md` rendern. 3. Hinweis in `PLAN.md` je nach Stufe: vor der Freigabe "Änderungen in plan.json", danach "Änderungen siehe Änderungsprotokoll". ## 3. Befund: grill-me fragt nicht nach dem Iris-Systemprompt (größte inhaltliche Lücke) Das Plugin hatte laut Plan `systemprompt: false`. Folge im Praxistest: Der Auto-Modus der App wählte nur "Canvas System" (die Anfrage enthielt "im Canvas"), Hermes lud den Skill nie, las einen 37-KB-Canvas-Skill und schrieb ein Eigenbau-Skript (zufällig mit demselben Namen `claude_sessions.py`). Erst ein eigener Systemprompt mit `usage` ("Claude Code Chats verwalten …") löste das. Das hat vier Testrunden gekostet. ### Vorschläge 1. **Neues Pflichtthema im grill-me: "Systemprompt und Auto-Modus"**, mit der Empfehlung "ja" für jedes Plugin, das per Chat oder Canvas bedient wird, und "nein" nur bei reinen Hintergrund-Plugins. Das Thema fragt nach der `usage`-Formulierung (sie entscheidet über die Auto-Auswahl) und nach Nachbar-Prompts, gegen die es sich abgrenzen muss ("Canvas System", `iris-gui`, `claude-code`). 2. **Das Gerüst erzeugt `system_prompt.md` und die Manifest-Felder** (`system_prompt`, `system_prompt_name`, `system_prompt_usage`), wenn das Thema "ja" ergibt, mit einem Baustein für die Aufrufe, die das Modell wörtlich übernehmen soll. 3. **`pruefen` prüft die Konsistenz:** Manifest-Felder und `system_prompt.md` müssen zusammenpassen, der Skill-Name muss im Prompt vorkommen, die `usage` darf nicht leer sein. ## 4. Befund: Praxistest ist nur über die Registry vorgesehen, Testverteilung fehlt - `veroeffentlichen` ist erst nach "Praxistest bestanden" erlaubt, der Test setzt aber ein installiertes Plugin voraus. Mein Weg: `build-irisplugin.sh` mit `OUTPUT_DIR`, dann `scp` auf den zweiten Rechner und dort per GUI importieren. Der Skill kennt diesen Weg nicht, `pruefen` baut das Paket nur zur Probe und wirft es weg. - Pro Test-Runde musste ich `version` in `plugin.json` von Hand hochzählen (0.1.0 bis 0.1.8), damit der Import ersetzt. ### Vorschläge 1. Befehl **`paket`**: baut `<id>-<version>.irisplugin` (Standard `~/Desktop`) und zählt auf Wunsch (`--patch`) die Version hoch. 2. Befehl **`paket --nach <host>`**: kopiert das Paket per `scp` auf einen in der Konfiguration genannten Testrechner. 3. In die Doku (`bauen`): "Test auf einem zweiten Rechner" mit genau diesem Ablauf, einschließlich der Prüfung, **ob die laufende App neuer ist als die Route/Funktion, die das Plugin braucht** (hier: HTTP 401, weil die App vom Vortag stammte). Ein Befehl `pruefen --app` könnte die gebaute App nach den erwarteten Routen durchsuchen. ## 5. Befund: Panel "Verbindung testen" liefert 403 trotz richtigem Token Der Test fragt `GET /api/v1/user` ab (braucht den Scope `read:user`), die Anleitung im Panel empfiehlt aber nur Repository- und Issue-Schreibrecht. Ein so angelegtes Token bekommt 403, obwohl es für Issues, Branches und PRs reicht. ### Vorschläge 1. Als Anmeldeprüfung `GET /api/v1/repos/<repo>` verwenden (liefert `permissions.push`), `/user` entfällt. 2. Die Antwort von Forgejo (`message`) im Detail mitzeigen statt nur "antwortet 403". 3. In der Anleitung den Scope benennen, falls `read:user` doch gebraucht wird. ## 6. Kleinere Stolpersteine - **Globale Optionen stehen vor dem Unterbefehl:** `plugin_dev.py status --vorhaben <id>` scheitert mit "unrecognized arguments"; richtig ist `--home … --vorhaben … status`. Die SKILL.md zeigt es nicht eindeutig. Vorschlag: Optionen auch nach dem Unterbefehl akzeptieren. - **`PD="python3 -I …"` aus der SKILL.md funktioniert in zsh nicht** (`$PD` wird nicht in Wörter zerlegt, "no such file or directory"). Vorschlag: ein kleines Wrapper-Skript `plugin-dev` statt einer Variablen, oder `${=PD}` dokumentieren. - **Skills müssen ohne `execute_code` auskommen:** auf dem `api_server` (unattended) wird es blockiert, das Modell wich auf das `terminal`-Werkzeug aus. Die Skill-Vorlage und die Doku sollten das sagen ("nur `terminal`, kein `execute_code`"). - **Nach einem Klick im Canvas improvisiert das Modell:** Es meldete einmal "umbenannt", ohne das Skript zu rufen (Request-Dump `~/.hermes/sessions/request_dump_*.json` zeigte das). Skripte sollten tolerant sein und den Aufruf im Prompt wörtlich nennen (hier gelöst). Das ist ein Hinweis für die Skill-Vorlage; eine strukturelle Lösung wäre ein App-seitiger Klick-Handler (eigenes Thema, nicht hier). - **`repo senden` erinnert nicht an Versionsnummer und `PLAN.md`:** Eine Prüfung "Version seit dem letzten Paket gleich geblieben?" wäre hilfreich. - **Beim Gerüst fehlt ein Canvas-Baustein:** Für Plugins mit Canvas wären ein `canvas`-Befehl, ein `auswahl`-Befehl (Rückmeldung auswerten) und die Tests dazu als Vorlage hilfreich. Diese beiden Befehle waren die Kernstücke von `iris-claude-sessions`. ## 7. Was gut funktioniert hat (beibehalten) - grill-me mit **einer Frage zur Zeit und einer Empfehlung** je Thema; "Grill-me fertig" und "Plan passt" bleiben beim Nutzer. - Die **Sperren pro Stufe** (kein Veröffentlichen ohne Praxistest) und das Protokoll der Freigaben mit Wortlaut. - `pruefen` (TODO-Marker, Tests, Manifest, Paketbau) in einem Schritt und `stand-kommentar` ins Issue. - `repo anlegen` legt Issue, Branch und PR sauber an und merged nie von selbst. ## Vorschlag für die Reihenfolge 1. Arbeitsordner und Klone fest und außerhalb von Repos (Abschnitt 1, Punkte 1 bis 4), weil das den Nutzer am meisten verwirrt. 2. grill-me-Thema "Systemprompt" plus Gerüst und Prüfung (Abschnitt 3), weil es den größten Zeitverlust verursacht hat. 3. `paket` und `paket --nach` (Abschnitt 4). 4. Panel-Anmeldeprüfung (Abschnitt 5). 5. `plan aendern` (Abschnitt 2) und die kleineren Punkte (Abschnitt 6). Bezug: iris/iris-plugins#167 (`iris-claude-sessions`, Fundstelle), iris/iris-plugins#99 (Plan des Skills), iris/Iris#130 und iris/Iris#132 (Auslöser des Plugins).
alf commented 2026-10-21 16:46:58 +00:00
Author
Owner
Copy link

Nachtrag aus dem Lauf (Stufe Store/Veröffentlichen)

  • repo senden nach dem Merge: Der Befehl pusht auf den alten, schon gemergten Branch 167-… und meldet nur „PR #168: gemergt“. Es entsteht kein neuer PR, und das Material kommt nicht auf main. Auf Stufe 9 steht repo senden außerdem nicht in der Liste der erlaubten Befehle, obwohl veroeffentlichen den Befehl in seiner Fehlermeldung verlangt („repo senden und den PR erneut mergen lassen“). Ich habe von Hand einen frischen Branch von main mit nur den Store-Dateien angelegt (PR #172).
    Vorschlag: repo senden erkennt einen gemergten PR und legt von selbst einen Folge-Branch NN-<id>-2 von main samt neuem PR an; der Zustand merkt sich den aktuellen PR.
  • --home innerhalb des Klons: Wer --home auf den Klon zeigen lässt (naheliegend, weil dort das Plugin liegt), bekommt in <home>/_klone/ einen zweiten Klon, diesmal der Registry (iris-plugin-registry, für den Dry-Run). Das ist dieselbe Verwirrung wie in Abschnitt 1: Arbeitsordner und Klone gehören an einen festen Ort außerhalb jedes Repos.
  • Store ohne Bilder besteht die Prüfung. store pruefen meldet den Beleg „erfüllt“, auch wenn weder custom.md noch Bilder da sind; store bilder-bestaetigt wurde nie verlangt. Das ist in Ordnung, die Doku sollte es aber sagen (Bilder optional, aber „nur echte“).
## Nachtrag aus dem Lauf (Stufe Store/Veröffentlichen) - **`repo senden` nach dem Merge:** Der Befehl pusht auf den alten, schon gemergten Branch `167-…` und meldet nur „PR #168: gemergt“. Es entsteht kein neuer PR, und das Material kommt nicht auf `main`. Auf Stufe 9 steht `repo senden` außerdem nicht in der Liste der erlaubten Befehle, obwohl `veroeffentlichen` den Befehl in seiner Fehlermeldung verlangt („`repo senden` und den PR erneut mergen lassen“). Ich habe von Hand einen frischen Branch von `main` mit nur den Store-Dateien angelegt (PR #172). Vorschlag: `repo senden` erkennt einen gemergten PR und legt von selbst einen Folge-Branch `NN-<id>-2` von `main` samt neuem PR an; der Zustand merkt sich den aktuellen PR. - **`--home` innerhalb des Klons:** Wer `--home` auf den Klon zeigen lässt (naheliegend, weil dort das Plugin liegt), bekommt in `<home>/_klone/` einen zweiten Klon, diesmal der Registry (`iris-plugin-registry`, für den Dry-Run). Das ist dieselbe Verwirrung wie in Abschnitt 1: Arbeitsordner und Klone gehören an einen festen Ort außerhalb jedes Repos. - **Store ohne Bilder besteht die Prüfung.** `store pruefen` meldet den Beleg „erfüllt“, auch wenn weder `custom.md` noch Bilder da sind; `store bilder-bestaetigt` wurde nie verlangt. Das ist in Ordnung, die Doku sollte es aber sagen (Bilder optional, aber „nur echte“).
alf commented 2026-10-21 17:14:36 +00:00
Author
Owner
Copy link

PR #174 gemergt: feat(plugin-dev): Arbeitsordner nie in einem Git-Repo, relative Pfade für übertragbare Chats, pfad und aufraeumen, Folge-PR nach dem Merge (#171)
#174

Commits:

  • feat(plugin-dev): Arbeitsordner nie in einem Git-Repo, relative Pfade für übertragbare Chats, pfad und aufraeumen, Folge-PR nach dem Merge (#171)
PR #174 gemergt: feat(plugin-dev): Arbeitsordner nie in einem Git-Repo, relative Pfade für übertragbare Chats, pfad und aufraeumen, Folge-PR nach dem Merge (#171) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/174 Commits: - feat(plugin-dev): Arbeitsordner nie in einem Git-Repo, relative Pfade für übertragbare Chats, pfad und aufraeumen, Folge-PR nach dem Merge (#171)
alf commented 2026-10-21 17:14:54 +00:00
Author
Owner
Copy link

Etappe 1 gemergt (PR #174): Arbeitsordner, Klone, Folge-PR

Entscheidung des Nutzers: Der Arbeitsordner bleibt im Workspace des Chats (./plugin-dev), damit sich der Chat samt Vorhaben auf eine andere Iris übertragen oder an Kollegen weitergeben lässt. Das ersetzt meinen Vorschlag mit einem festen Ordner außerhalb. Zwei Funde im Code haben den Plan dafür geändert: Ein Chat-Export (ChatBundleBuilder) kopiert den ganzen Workspace ohne Ausnahme, und Symlinks bleiben darin Symlinks. Der Symlink-Vorschlag entfiel, und absolute Pfade hätten nach einer Übertragung ins Leere gezeigt.

Geändert

  • Git-Schutz: Jeder Befehl, der im Arbeitsordner etwas anlegt (neu, repo anlegen, vorhaben-holen, Registry- und Veröffentlichen-Klone), bricht ab, wenn der Ordner in einem Git-Repo liegt, mit klarer Meldung. Ein Repo direkt im Home-Verzeichnis (Dotfiles) zählt nicht. Das verhindert Vorhaben im Repo und den Klon im Klon (Abschnitt 1 und Nachtrag).
  • Relative Pfade: .dev/umzug.json speichert nach relativ zum Vorhabenordner, der Klon ergibt sich aus dem Ort des Plugin-Verzeichnisses; repo.klon ist aus dem Zustand entfernt. Ältere absolute Vermerke werden weiter gelesen. Der ganze Arbeitsordner kann verschoben werden (getestet).
  • pfad gibt nur den Ort aus, status zeigt ihn als Ort:.
  • aufraeumen entfernt die Klone (Plugin-Repo etwa 60 MB, Registry etwa 10 MB gegenüber 0,1 MB für das Vorhaben), nur wenn nichts Ungesichertes darin liegt (nicht committet oder nicht auf Forgejo); danach holt vorhaben-holen <id> das Vorhaben wieder. Die Meldung bei fehlendem Klon nennt genau diesen Befehl.
  • repo senden nach dem Merge: fragt den PR ab; ist er gemergt, legt es <NN-id>-<k> von main an (Änderungen per git stash), pusht, öffnet einen neuen PR und trägt ihn im Zustand ein (repo.vorherige).
  • Der Test, der noch {status, save, test} erwartete, kennt jetzt auch config-status (seit #147 im Manifest; war auf main rot). Version des Plugins 0.1.2.

Gemessen: 152 Tests grün (117 vorhandene, 35 neue in tests/test_arbeitsordner.py: Git-Schutz tief und nicht vorhanden, Dotfile-Repo im Home, Verschieben des Arbeitsordners, Senden nach dem Verschieben, fehlender Klon, alter absoluter Vermerk, pfad, aufraeumen mit allen Verweigerungen und dem Wiederholen per vorhaben-holen, Folge-PR inklusive Zustand, zweiter Folge-PR, nichts zu senden).

Grenzen

  • Nicht im echten Betrieb gelaufen und nicht veröffentlicht: Das installierte iris-plugin-dev auf den Rechnern ist weiter 0.1.1. Veröffentlichen geht per publish-plugins.sh und wartet auf dein Okay.
  • Der Folge-PR nutzt git stash pop; bei einem Konflikt bricht er mit Meldung ab und lässt den Stash im Klon (selten, nicht getestet gegen echte Konflikte).
  • Ob das Home im Linux-Container erhalten bleibt, ist nicht geprüft. Der Arbeitsordner liegt jetzt (wie vorher) im Workspace.
  • Der Name _klone bleibt (Abschnitt 1 sagte, er verwirre; mit Git-Schutz und pfad liegt er nur noch im Workspace des Chats).

Offen (nächste Etappen): 2 Systemprompt im grill-me (Pflichtthema, Gerüst, Prüfung); 3 paket und paket --nach; 4 Panel-Anmeldeprüfung (/user → /repos/<repo>); 5 plan aendern und die kleineren Punkte.

## Etappe 1 gemergt (PR #174): Arbeitsordner, Klone, Folge-PR **Entscheidung des Nutzers:** Der Arbeitsordner bleibt im **Workspace des Chats** (`./plugin-dev`), damit sich der Chat samt Vorhaben auf eine andere Iris übertragen oder an Kollegen weitergeben lässt. Das ersetzt meinen Vorschlag mit einem festen Ordner außerhalb. Zwei Funde im Code haben den Plan dafür geändert: Ein Chat-Export (`ChatBundleBuilder`) kopiert den **ganzen** Workspace ohne Ausnahme, und Symlinks bleiben darin Symlinks. Der Symlink-Vorschlag entfiel, und absolute Pfade hätten nach einer Übertragung ins Leere gezeigt. **Geändert** - **Git-Schutz:** Jeder Befehl, der im Arbeitsordner etwas anlegt (`neu`, `repo anlegen`, `vorhaben-holen`, Registry- und Veröffentlichen-Klone), bricht ab, wenn der Ordner in einem Git-Repo liegt, mit klarer Meldung. Ein Repo direkt im Home-Verzeichnis (Dotfiles) zählt nicht. Das verhindert Vorhaben im Repo und den Klon im Klon (Abschnitt 1 und Nachtrag). - **Relative Pfade:** `.dev/umzug.json` speichert `nach` relativ zum Vorhabenordner, der Klon ergibt sich aus dem Ort des Plugin-Verzeichnisses; `repo.klon` ist aus dem Zustand entfernt. Ältere absolute Vermerke werden weiter gelesen. Der ganze Arbeitsordner kann verschoben werden (getestet). - **`pfad`** gibt nur den Ort aus, `status` zeigt ihn als `Ort:`. - **`aufraeumen`** entfernt die Klone (Plugin-Repo etwa 60 MB, Registry etwa 10 MB gegenüber 0,1 MB für das Vorhaben), nur wenn nichts Ungesichertes darin liegt (nicht committet oder nicht auf Forgejo); danach holt `vorhaben-holen <id>` das Vorhaben wieder. Die Meldung bei fehlendem Klon nennt genau diesen Befehl. - **`repo senden` nach dem Merge:** fragt den PR ab; ist er gemergt, legt es `<NN-id>-<k>` von `main` an (Änderungen per `git stash`), pusht, öffnet einen neuen PR und trägt ihn im Zustand ein (`repo.vorherige`). - Der Test, der noch `{status, save, test}` erwartete, kennt jetzt auch `config-status` (seit #147 im Manifest; war auf `main` rot). Version des Plugins 0.1.2. **Gemessen:** 152 Tests grün (117 vorhandene, 35 neue in `tests/test_arbeitsordner.py`: Git-Schutz tief und nicht vorhanden, Dotfile-Repo im Home, Verschieben des Arbeitsordners, Senden nach dem Verschieben, fehlender Klon, alter absoluter Vermerk, `pfad`, `aufraeumen` mit allen Verweigerungen und dem Wiederholen per `vorhaben-holen`, Folge-PR inklusive Zustand, zweiter Folge-PR, nichts zu senden). **Grenzen** - Nicht im echten Betrieb gelaufen und **nicht veröffentlicht**: Das installierte iris-plugin-dev auf den Rechnern ist weiter 0.1.1. Veröffentlichen geht per `publish-plugins.sh` und wartet auf dein Okay. - Der Folge-PR nutzt `git stash pop`; bei einem Konflikt bricht er mit Meldung ab und lässt den Stash im Klon (selten, nicht getestet gegen echte Konflikte). - Ob das Home im Linux-Container erhalten bleibt, ist nicht geprüft. Der Arbeitsordner liegt jetzt (wie vorher) im Workspace. - Der Name `_klone` bleibt (Abschnitt 1 sagte, er verwirre; mit Git-Schutz und `pfad` liegt er nur noch im Workspace des Chats). **Offen (nächste Etappen):** 2 Systemprompt im grill-me (Pflichtthema, Gerüst, Prüfung); 3 `paket` und `paket --nach`; 4 Panel-Anmeldeprüfung (`/user` → `/repos/<repo>`); 5 `plan aendern` und die kleineren Punkte.
alf commented 2026-10-21 17:53:56 +00:00
Author
Owner
Copy link

PR #176 gemergt: feat(plugin-dev): Systemprompt als Pflichtthema im grill-me, Verwendungssatz im Plan, Prompt-Baustein im Gerüst, Plan und Manifest im Einklang (#171)
#176

Commits:

  • feat(plugin-dev): Systemprompt als Pflichtthema im grill-me, Verwendungssatz im Plan, Prompt-Baustein im Gerüst, Plan und Manifest im Einklang (#171)
PR #176 gemergt: feat(plugin-dev): Systemprompt als Pflichtthema im grill-me, Verwendungssatz im Plan, Prompt-Baustein im Gerüst, Plan und Manifest im Einklang (#171) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/176 Commits: - feat(plugin-dev): Systemprompt als Pflichtthema im grill-me, Verwendungssatz im Plan, Prompt-Baustein im Gerüst, Plan und Manifest im Einklang (#171)
alf commented 2026-10-21 17:54:16 +00:00
Author
Owner
Copy link

Etappe 2 gemergt (PR #176): Systemprompt im grill-me, Plan, Gerüst und Prüfung

Korrektur zum Issue: Ich hatte geschrieben, das Plan-Format kenne kein Feld für den Systemprompt. Das stimmt nicht: plan.json hatte systemprompt (Standard false), das Gerüst erzeugte system_prompt.md, und pruefen prüfte, dass die Datei existiert. Was fehlte, ist das, was den Fehler im Praxistest wirklich ausgelöst hat: Niemand fragte danach, der Verwendungssatz (usage) war nur ein TODO:-Platzhalter, PLAN.md zeigte die Entscheidung nicht, und die Konsistenzprüfung verglich systemprompt nicht zwischen Plan und Manifest (nur Kategorie, requires, Plattformen, Skills). Deshalb fiel es bei iris-claude-sessions nicht auf, dass das Manifest einen Systemprompt hatte, der Plan aber false sagte.

Geändert

  • grill-me: neues Pflichtthema systemprompt („Systemprompt und Auto-Modus“, nach skills). Der Hinweis erklärt den Grund: Der Auto-Modus wählt Prompts nur nach der usage, sonst gewinnt ein Nachbar wie „Canvas System“. Überspringbar nur mit Grund (reine Hintergrund-Plugins). Bestehende Freigaben bleiben gültig (Fingerabdruck von grill.json ändert sich nicht).
  • Plan: neues Feld systemprompt_usage, Pflicht bei systemprompt: true (mindestens 20 Zeichen, kein TODO); ohne Systemprompt nur eine Warnung. PLAN.md zeigt den Abschnitt „Systemprompt“.
  • Gerüst: Manifest-Felder system_prompt, system_prompt_name, system_prompt_usage mit dem Satz aus dem Plan; system_prompt.md als Baustein (Auslöser, Skill beim Namen mit skill_view, feste Regeln aus dem Betrieb: Erfolg nur nach Skript-Ausgabe, kein eigenes Skript, kein execute_code) und einer TODO:-Stelle für das Routing.
  • Prüfung: pruefen meldet jetzt eine Abweichung zwischen Plan und Manifest bei system_prompt, eine zu kurze oder fehlende system_prompt_usage, und einen system_prompt.md, der einen Skill des Plugins nicht nennt.
  • Issue-Text beim Anlegen nennt „Systemprompt: ja/nein“.
  • README (Kapitel 11, geht in docs/): Abschnitt „Wann ein Plugin einen Systemprompt braucht“ mit den Regeln aus dem Lauf (usage-Satz, wörtliche Aufrufe, Anfrage und Canvas-Rückmeldung trennen, tolerante Skripte, Request-Dump als Beleg). SKILL.md: Empfehlung „ja“ bei Chat oder Canvas. Version 0.1.3.

Gemessen: 162 Tests grün (152 vorher, 10 neu in test_grill, test_plan_geruest, test_pruefen; zwei vorhandene angepasst: Themenzahl 10, Plan mit Systemprompt braucht usage). Gegenprobe: Ohne die neuen Prüfungen werden drei Tests rot. Ein erzeugtes Gerüst habe ich angesehen (Manifest, system_prompt.md, PLAN.md).

Grenzen

  • Nicht im echten Betrieb gelaufen, nicht veröffentlicht (installiert ist 0.1.2 aus Etappe 1).
  • Der Prompt-Baustein ist ein Anfang; ob das Modell damit zuverlässig den Skill lädt, zeigt erst ein Praxistest (bei iris-claude-sessions brauchte es dafür den wörtlichen Aufruf im Prompt).
  • Die Prüfung vergleicht nur, ob der Skill-Name im Prompt steht, nicht ob das Routing sinnvoll ist.
  • iris-claude-sessions selbst würde jetzt „Plan weicht vom Manifest ab“ melden (Plan false, Manifest true); das lässt sich erst mit plan aendern (Etappe 5) sauber auflösen.

Offen: 3 paket und paket --nach; 4 Panel-Anmeldeprüfung; 5 plan aendern und die kleineren Punkte.

## Etappe 2 gemergt (PR #176): Systemprompt im grill-me, Plan, Gerüst und Prüfung **Korrektur zum Issue:** Ich hatte geschrieben, das Plan-Format kenne kein Feld für den Systemprompt. Das stimmt nicht: `plan.json` hatte `systemprompt` (Standard `false`), das Gerüst erzeugte `system_prompt.md`, und `pruefen` prüfte, dass die Datei existiert. Was fehlte, ist das, was den Fehler im Praxistest wirklich ausgelöst hat: Niemand fragte danach, der Verwendungssatz (`usage`) war nur ein `TODO:`-Platzhalter, `PLAN.md` zeigte die Entscheidung nicht, und die Konsistenzprüfung verglich `systemprompt` nicht zwischen Plan und Manifest (nur Kategorie, `requires`, Plattformen, Skills). Deshalb fiel es bei `iris-claude-sessions` nicht auf, dass das Manifest einen Systemprompt hatte, der Plan aber `false` sagte. **Geändert** - **grill-me:** neues Pflichtthema `systemprompt` („Systemprompt und Auto-Modus“, nach `skills`). Der Hinweis erklärt den Grund: Der Auto-Modus wählt Prompts nur nach der `usage`, sonst gewinnt ein Nachbar wie „Canvas System“. Überspringbar nur mit Grund (reine Hintergrund-Plugins). Bestehende Freigaben bleiben gültig (Fingerabdruck von `grill.json` ändert sich nicht). - **Plan:** neues Feld `systemprompt_usage`, Pflicht bei `systemprompt: true` (mindestens 20 Zeichen, kein `TODO`); ohne Systemprompt nur eine Warnung. `PLAN.md` zeigt den Abschnitt „Systemprompt“. - **Gerüst:** Manifest-Felder `system_prompt`, `system_prompt_name`, `system_prompt_usage` mit dem Satz aus dem Plan; `system_prompt.md` als Baustein (Auslöser, Skill beim Namen mit `skill_view`, feste Regeln aus dem Betrieb: Erfolg nur nach Skript-Ausgabe, kein eigenes Skript, kein `execute_code`) und einer `TODO:`-Stelle für das Routing. - **Prüfung:** `pruefen` meldet jetzt eine Abweichung zwischen Plan und Manifest bei `system_prompt`, eine zu kurze oder fehlende `system_prompt_usage`, und einen `system_prompt.md`, der einen Skill des Plugins nicht nennt. - **Issue-Text** beim Anlegen nennt „Systemprompt: ja/nein“. - **README** (Kapitel 11, geht in `docs/`): Abschnitt „Wann ein Plugin einen Systemprompt braucht“ mit den Regeln aus dem Lauf (usage-Satz, wörtliche Aufrufe, Anfrage und Canvas-Rückmeldung trennen, tolerante Skripte, Request-Dump als Beleg). SKILL.md: Empfehlung „ja“ bei Chat oder Canvas. Version 0.1.3. **Gemessen:** 162 Tests grün (152 vorher, 10 neu in `test_grill`, `test_plan_geruest`, `test_pruefen`; zwei vorhandene angepasst: Themenzahl 10, Plan mit Systemprompt braucht `usage`). Gegenprobe: Ohne die neuen Prüfungen werden drei Tests rot. Ein erzeugtes Gerüst habe ich angesehen (Manifest, `system_prompt.md`, `PLAN.md`). **Grenzen** - Nicht im echten Betrieb gelaufen, nicht veröffentlicht (installiert ist 0.1.2 aus Etappe 1). - Der Prompt-Baustein ist ein Anfang; ob das Modell damit zuverlässig den Skill lädt, zeigt erst ein Praxistest (bei `iris-claude-sessions` brauchte es dafür den wörtlichen Aufruf im Prompt). - Die Prüfung vergleicht nur, ob der Skill-Name im Prompt steht, nicht ob das Routing sinnvoll ist. - `iris-claude-sessions` selbst würde jetzt „Plan weicht vom Manifest ab“ melden (Plan `false`, Manifest `true`); das lässt sich erst mit `plan aendern` (Etappe 5) sauber auflösen. **Offen:** 3 `paket` und `paket --nach`; 4 Panel-Anmeldeprüfung; 5 `plan aendern` und die kleineren Punkte.
alf commented 2026-10-21 17:59:39 +00:00
Author
Owner
Copy link

PR #177 gemergt: fix(plugin-dev): Verbindungstest im Panel prüft Server, Repo mit Schreibrecht, Issues und Registry statt /user und zeigt Forgejos Meldung (#171)
#177

Commits:

  • fix(plugin-dev): Verbindungstest im Panel prüft Server, Repo mit Schreibrecht, Issues und Registry statt /user und zeigt Forgejos Meldung (#171)
PR #177 gemergt: fix(plugin-dev): Verbindungstest im Panel prüft Server, Repo mit Schreibrecht, Issues und Registry statt /user und zeigt Forgejos Meldung (#171) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/177 Commits: - fix(plugin-dev): Verbindungstest im Panel prüft Server, Repo mit Schreibrecht, Issues und Registry statt /user und zeigt Forgejos Meldung (#171)
alf commented 2026-10-21 18:00:04 +00:00
Author
Owner
Copy link

Etappe 4 gemergt (PR #177): Verbindungstest im Panel

Ursache des 403 (bestätigt): testen in panel_api.py fragte als Erstes GET /api/v1/user ab. Das verlangt den Scope read:user. Die Anleitung im Panel empfahl aber nur „Repository“ und „Issue“, ein so angelegtes Token war richtig und bekam trotzdem 403. Das Detail sagte nur „Forgejo antwortet 403“.

Geändert

  • Neue Schritte, nur lesend, nur Wege, die das Werkzeug selbst benutzt: Server (/version, bei „nicht erreichbar“ endet die Prüfung gleich), Repo (/repos/<repo>: Token gilt und permissions.push; daraus auch der Hinweis auf Admin-Rechte), Issues (Lesezugriff; zeigt, ob das Recht „Issue“ überhaupt da ist), Registry (lesbar). /user wird nicht mehr abgefragt.
  • Forgejos eigene Meldung steht im Detail (zum Beispiel token does not have at least one of required scope(s): [read:issue]), dazu je Fall ein Hinweis, was zu tun ist (Token ungültig oder abgelaufen; Recht „Repository“ oder „Issue“ fehlt; Repo nicht gefunden). Das Token wird in jeder Meldung geschwärzt.
  • Hinweistext im Panel: Zugriff auf Benutzerdaten ist nicht nötig.

Gemessen: 172 Tests grün (162 vorher, 10 neu in tests/test_panel_pruefung.py gegen eine Attrappe, die je nach Token antwortet: nur Repository und Issue, ohne Issue-Recht, nur lesend, Admin, ungültig, unbekanntes Repo, Server nicht erreichbar, fehlende Eingaben; Regressionstest: ein Token ohne read:user besteht, und /api/v1/user wird nicht aufgerufen). Gegenprobe: Mit dem alten /user-Aufruf wird genau dieser Test rot. Außerdem gegen den echten Forgejo gelaufen (lesend, mit dem Token des Entwicklers, das nirgends im Ergebnis steht): Server, Repo mit Schreibrecht, Issues und Registry grün; der Admin-Hinweis erscheint, weil dieses Token Admin-Rechte hat.

Grenzen

  • Nicht veröffentlicht: Installiert ist weiter 0.1.2, die Fixes (Etappe 2 und 4) stecken in 0.1.3. Das Panel auf den Rechnern zeigt den 403, bis das Plugin aktualisiert ist.
  • Das Schreibrecht auf Issues lässt sich nur durch Schreiben prüfen; der Test sagt das offen.
  • Die Oberfläche (web/settings.html) habe ich nicht im Marktplatz-Fenster angesehen, nur den Hinweistext geändert.

Offen: 3 paket und paket --nach; 5 plan aendern und die kleineren Punkte.

## Etappe 4 gemergt (PR #177): Verbindungstest im Panel **Ursache des 403 (bestätigt):** `testen` in `panel_api.py` fragte als Erstes `GET /api/v1/user` ab. Das verlangt den Scope `read:user`. Die Anleitung im Panel empfahl aber nur „Repository“ und „Issue“, ein so angelegtes Token war richtig und bekam trotzdem 403. Das Detail sagte nur „Forgejo antwortet 403“. **Geändert** - **Neue Schritte, nur lesend, nur Wege, die das Werkzeug selbst benutzt:** *Server* (`/version`, bei „nicht erreichbar“ endet die Prüfung gleich), *Repo* (`/repos/<repo>`: Token gilt und `permissions.push`; daraus auch der Hinweis auf Admin-Rechte), *Issues* (Lesezugriff; zeigt, ob das Recht „Issue“ überhaupt da ist), *Registry* (lesbar). `/user` wird nicht mehr abgefragt. - **Forgejos eigene Meldung** steht im Detail (zum Beispiel `token does not have at least one of required scope(s): [read:issue]`), dazu je Fall ein Hinweis, was zu tun ist (Token ungültig oder abgelaufen; Recht „Repository“ oder „Issue“ fehlt; Repo nicht gefunden). Das Token wird in jeder Meldung geschwärzt. - Hinweistext im Panel: Zugriff auf Benutzerdaten ist nicht nötig. **Gemessen:** 172 Tests grün (162 vorher, 10 neu in `tests/test_panel_pruefung.py` gegen eine Attrappe, die je nach Token antwortet: nur Repository und Issue, ohne Issue-Recht, nur lesend, Admin, ungültig, unbekanntes Repo, Server nicht erreichbar, fehlende Eingaben; Regressionstest: ein Token ohne `read:user` besteht, und `/api/v1/user` wird nicht aufgerufen). Gegenprobe: Mit dem alten `/user`-Aufruf wird genau dieser Test rot. Außerdem gegen den echten Forgejo gelaufen (lesend, mit dem Token des Entwicklers, das nirgends im Ergebnis steht): Server, Repo mit Schreibrecht, Issues und Registry grün; der Admin-Hinweis erscheint, weil dieses Token Admin-Rechte hat. **Grenzen** - **Nicht veröffentlicht:** Installiert ist weiter 0.1.2, die Fixes (Etappe 2 und 4) stecken in 0.1.3. Das Panel auf den Rechnern zeigt den 403, bis das Plugin aktualisiert ist. - Das **Schreibrecht auf Issues** lässt sich nur durch Schreiben prüfen; der Test sagt das offen. - Die Oberfläche (`web/settings.html`) habe ich nicht im Marktplatz-Fenster angesehen, nur den Hinweistext geändert. **Offen:** 3 `paket` und `paket --nach`; 5 `plan aendern` und die kleineren Punkte.
alf commented 2026-10-21 18:02:18 +00:00
Author
Owner
Copy link

Veröffentlicht: iris-plugin-dev 0.1.3

Registry-Commit fea8cdff. Gegen die Registry geprüft: Index trägt 0.1.3, Paket iris-plugin-dev-0.1.3.irisplugin (78 405 Byte), Versionsverlauf 0.1.1 bis 0.1.3 (die letzten drei bleiben). Probelauf vorher sauber (1 würde veröffentlicht).

Enthalten: Etappe 1 war schon in 0.1.2; neu in 0.1.3 sind Etappe 2 (Systemprompt im grill-me, Plan, Gerüst, Prüfung; PR #176) und Etappe 4 (Verbindungstest im Panel ohne /user; PR #177). Auf den Rechnern gilt das, sobald das Plugin dort aktualisiert wird (Marktplatz → Aktualisieren).

Offen bleiben Etappe 3 (paket, paket --nach) und 5 (plan aendern, kleinere Punkte). Das Issue bleibt offen.

## Veröffentlicht: iris-plugin-dev 0.1.3 Registry-Commit `fea8cdff`. Gegen die Registry geprüft: Index trägt 0.1.3, Paket `iris-plugin-dev-0.1.3.irisplugin` (78 405 Byte), Versionsverlauf 0.1.1 bis 0.1.3 (die letzten drei bleiben). Probelauf vorher sauber (1 würde veröffentlicht). Enthalten: Etappe 1 war schon in 0.1.2; neu in 0.1.3 sind Etappe 2 (Systemprompt im grill-me, Plan, Gerüst, Prüfung; PR #176) und Etappe 4 (Verbindungstest im Panel ohne `/user`; PR #177). Auf den Rechnern gilt das, sobald das Plugin dort aktualisiert wird (Marktplatz → Aktualisieren). Offen bleiben Etappe 3 (`paket`, `paket --nach`) und 5 (`plan aendern`, kleinere Punkte). Das Issue bleibt offen.
alf closed this issue 2026-10-21 23:03:31 +00:00
alf commented 2026-10-26 21:00:01 +00:00
Author
Owner
Copy link

PR #303 gemergt: fix(iris-plugin-dev): Issue-Text verträgt Grill-Einträge mit freiem Themenschlüssel (0.1.19, #171)
#303

Commits:

  • fix(iris-plugin-dev): Issue-Text verträgt Grill-Einträge mit freiem Themenschlüssel (0.1.19, #171)

Stand 0.1.19 — Fehler beim Anlegen des Repos behoben

Befund: Im ersten Praxislauf (Plugin iris-buchhaltung) brach das Anlegen von Repo und Issue mit KeyError ab, weil issue_text in pd_forgejo.py den Titel jedes Grill-Eintrags in der Liste der Pflichtthemen nachschlug; ein Eintrag mit freiem Themenschlüssel (in grill.json von Hand geschrieben) ist dort nicht. Der Chat hat die installierte Kopie von Hand gepatcht; Quelle und Registry hatten den Fehler weiter, ein Update hätte den Patch überschrieben.

Geändert: issue_text nimmt für unbekannte Themenschlüssel den Schlüssel selbst (titel.get(thema, thema), auch bei „nicht nötig“). Neuer Test in tests/test_forgejo.py (rot mit KeyError: 'anbindung' ohne die Korrektur, grün mit). Version 0.1.19, Änderungstext, store/changelog.md, Lessons Learned in PLAN.md.

Geprüft: Gesamte Testsuite des Plugins (235 Tests) grün; die Zeile der Quelle ist jetzt gleich der von Hand gepatchten installierten Kopie.

Nicht geprüft: Ein erneuter Lauf des Anlegens in der echten App.

Offen: Die Ursache des freien Schlüssels (das Modell hat grill.json am Werkzeug vorbei geschrieben, hinzufuegen lehnt unbekannte Themen ab) bleibt; Idee: laden meldet unbekannte Schlüssel oder hinzufuegen-Fehlermeldung nennt die gültigen Themen früher.

PR #303 gemergt: fix(iris-plugin-dev): Issue-Text verträgt Grill-Einträge mit freiem Themenschlüssel (0.1.19, #171) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/303 Commits: - fix(iris-plugin-dev): Issue-Text verträgt Grill-Einträge mit freiem Themenschlüssel (0.1.19, #171) --- **Stand 0.1.19 — Fehler beim Anlegen des Repos behoben** **Befund:** Im ersten Praxislauf (Plugin `iris-buchhaltung`) brach das Anlegen von Repo und Issue mit `KeyError` ab, weil `issue_text` in `pd_forgejo.py` den Titel jedes Grill-Eintrags in der Liste der Pflichtthemen nachschlug; ein Eintrag mit freiem Themenschlüssel (in `grill.json` von Hand geschrieben) ist dort nicht. Der Chat hat die **installierte** Kopie von Hand gepatcht; Quelle und Registry hatten den Fehler weiter, ein Update hätte den Patch überschrieben. **Geändert:** `issue_text` nimmt für unbekannte Themenschlüssel den Schlüssel selbst (`titel.get(thema, thema)`, auch bei „nicht nötig“). Neuer Test in `tests/test_forgejo.py` (rot mit `KeyError: 'anbindung'` ohne die Korrektur, grün mit). Version 0.1.19, Änderungstext, `store/changelog.md`, Lessons Learned in `PLAN.md`. **Geprüft:** Gesamte Testsuite des Plugins (235 Tests) grün; die Zeile der Quelle ist jetzt gleich der von Hand gepatchten installierten Kopie. **Nicht geprüft:** Ein erneuter Lauf des Anlegens in der echten App. **Offen:** Die Ursache des freien Schlüssels (das Modell hat `grill.json` am Werkzeug vorbei geschrieben, `hinzufuegen` lehnt unbekannte Themen ab) bleibt; Idee: `laden` meldet unbekannte Schlüssel oder `hinzufuegen`-Fehlermeldung nennt die gültigen Themen früher.
alf commented 2026-10-26 21:00:09 +00:00
Author
Owner
Copy link

Veröffentlicht: Plugin „Plugins entwickeln“ (iris-plugin-dev) 0.1.19

  • Draußen: Version 0.1.19 in der Registry (nach dem Pull geprüft: packages/iris-plugin-dev/iris-plugin-dev-0.1.19.irisplugin).
  • Nutzer bekommen: Das Anlegen von Repo und Issue bricht nicht mehr mit KeyError ab, wenn das Grill-Protokoll einen Eintrag mit freiem Themenschlüssel enthält. Gefunden im ersten Praxislauf (Plugin iris-buchhaltung); der Chat hatte nur die installierte Kopie von Hand gepatcht.
  • Offen: Ursache des freien Schlüssels (Modell schreibt grill.json am Werkzeug vorbei) nicht behoben; erneuter Lauf in der App nicht geprüft.
**Veröffentlicht: Plugin „Plugins entwickeln“ (`iris-plugin-dev`) 0.1.19** - Draußen: Version 0.1.19 in der Registry (nach dem Pull geprüft: `packages/iris-plugin-dev/iris-plugin-dev-0.1.19.irisplugin`). - Nutzer bekommen: Das Anlegen von Repo und Issue bricht nicht mehr mit `KeyError` ab, wenn das Grill-Protokoll einen Eintrag mit freiem Themenschlüssel enthält. Gefunden im ersten Praxislauf (Plugin `iris-buchhaltung`); der Chat hatte nur die installierte Kopie von Hand gepatcht. - Offen: Ursache des freien Schlüssels (Modell schreibt `grill.json` am Werkzeug vorbei) nicht behoben; erneuter Lauf in der App nicht geprüft.
alf commented 2026-10-26 22:46:41 +00:00
Author
Owner
Copy link

PR #304 gemergt: feat(iris-plugin-dev): Seitenpanel im Plan, Grill, Gerüst und Prüfung (0.1.20, #171)
#304

Commits:

  • feat(iris-plugin-dev): Seitenpanel im Plan, Grill, Gerüst und Prüfung (0.1.20, #171)

Stand 0.1.20 — Seitenpanel im Werkzeug, Auswertung des ersten Praxislaufs (Plugin iris-buchhaltung, Wegwerf-Test)

Befund aus dem Praxislauf (26.10.): Mit „Plugins entwickeln“ entstand aus einer Websuche ein vollständiges Plugin: Grill-me (11 Themen, Antworten bündelbar), Plan, Gerüst, Repo mit Issue und PR (#301/#302, gemergt), Umsetzung, Rauchtest gegen einen vom Chat selbst aufgebauten Frappe-Stack, Anleitung, Einstellungsfenster („Verbindung steht“, 1 Treffer in der Kundentabelle) und Reiter im Seitenpanel (Rechnungen, Neue Rechnung, Kunden, Artikel, Umsatz; Zusammenfassung „1 offene Posten über 285,60 € · 3 Entwürfe“). Dabei fielen auf:

  1. Einstellungsfenster: Tippfehler in zeigeStatus (0.1.18).
  2. Anlegen von Repo und Issue: KeyError bei freiem Themenschlüssel in grill.json (0.1.19); der Chat hatte die installierte Kopie von Hand gepatcht.
  3. Seitenpanel-Vertrag fehlt im Werkzeug (dieser Stand): Der Reiter hatte nur status + revision, keine Auswahl und keinen Ansichtszustand. Der Systemprompt versprach „der Reiter zeigt …“; das Modell suchte 2:26 Min. nach einem Weg, den Reiter zu öffnen. Grill-me, Plan, Gerüst und pruefen kannten side_panel nicht.

Geändert (0.1.20):

  • Grill: neues Pflichtthema seitenpanel (11 statt 10), überspringbar mit Grund.
  • Plan: optionales Feld seitenpanel {zweck, auswahl, agent_steuert}, geprüft, in PLAN.md ausgegeben.
  • Gerüst: bei einem Reiter side_panel, panel_api mit den Befehlen laut Plan (status; select/selection; view-set), panel_api.py und web/panel.html als Vorlage mit TODO:, Kit-Kopie im Build-Skript, Regel im Systemprompt (Agent steuert über view bzw. „kann den Reiter weder öffnen noch bedienen“).
  • pruefen: Plan und Manifest müssen übereinstimmen (Reiter ja/nein, Dateien, versprochene Befehle); Warnung, wenn der Prompt bei fehlender Steuerung nichts dazu sagt.
  • 9 neue Tests (rot ohne die Korrektur), docs/erste-schritte.md und SKILL.md angepasst.

Geprüft: Gesamte Testsuite des Plugins (245 Tests) grün; die neuen Prüfungen schlagen ohne die Änderung an pd_pruefen.py fehl.

Nicht geprüft: Ein ganzer Lauf mit einem neuen Plugin in der App (Grill-me bis Reiter); die Vorlage panel_api.py wurde nur auf Syntax geprüft, nicht gegen das echte Kit ausgeführt; der Chat-Weg von iris-buchhaltung („leg eine Rechnung an“) ist nicht abschließend bewertet.

Offen:

  • Das Modell schreibt Dateien am Werkzeug vorbei (grill.json von Hand, installierte Kopie gepatcht): Idee laden meldet unbekannte Themenschlüssel.
  • Aufruflimit 90 Aufrufe je Runde zwingt zu „mach weiter“ (max_iterations, Einstellung beim Nutzer).
  • Bestehende Pläne ohne seitenpanel bleiben gültig; ein Plugin mit side_panel im Manifest und ohne Eintrag im Plan wird jetzt von pruefen beanstandet.
PR #304 gemergt: feat(iris-plugin-dev): Seitenpanel im Plan, Grill, Gerüst und Prüfung (0.1.20, #171) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/304 Commits: - feat(iris-plugin-dev): Seitenpanel im Plan, Grill, Gerüst und Prüfung (0.1.20, #171) --- **Stand 0.1.20 — Seitenpanel im Werkzeug, Auswertung des ersten Praxislaufs (Plugin `iris-buchhaltung`, Wegwerf-Test)** **Befund aus dem Praxislauf (26.10.):** Mit „Plugins entwickeln“ entstand aus einer Websuche ein vollständiges Plugin: Grill-me (11 Themen, Antworten bündelbar), Plan, Gerüst, Repo mit Issue und PR (#301/#302, gemergt), Umsetzung, Rauchtest gegen einen vom Chat selbst aufgebauten Frappe-Stack, Anleitung, Einstellungsfenster („Verbindung steht“, 1 Treffer in der Kundentabelle) und Reiter im Seitenpanel (Rechnungen, Neue Rechnung, Kunden, Artikel, Umsatz; Zusammenfassung „1 offene Posten über 285,60 € · 3 Entwürfe“). Dabei fielen auf: 1. Einstellungsfenster: Tippfehler in `zeigeStatus` (0.1.18). 2. Anlegen von Repo und Issue: `KeyError` bei freiem Themenschlüssel in `grill.json` (0.1.19); der Chat hatte die installierte Kopie von Hand gepatcht. 3. **Seitenpanel-Vertrag fehlt im Werkzeug (dieser Stand):** Der Reiter hatte nur `status` + `revision`, keine Auswahl und keinen Ansichtszustand. Der Systemprompt versprach „der Reiter zeigt …“; das Modell suchte 2:26 Min. nach einem Weg, den Reiter zu öffnen. Grill-me, Plan, Gerüst und `pruefen` kannten `side_panel` nicht. **Geändert (0.1.20):** - Grill: neues Pflichtthema `seitenpanel` (11 statt 10), überspringbar mit Grund. - Plan: optionales Feld `seitenpanel` `{zweck, auswahl, agent_steuert}`, geprüft, in `PLAN.md` ausgegeben. - Gerüst: bei einem Reiter `side_panel`, `panel_api` mit den Befehlen laut Plan (`status`; `select`/`selection`; `view-set`), `panel_api.py` und `web/panel.html` als Vorlage mit `TODO:`, Kit-Kopie im Build-Skript, Regel im Systemprompt (Agent steuert über `view` bzw. „kann den Reiter weder öffnen noch bedienen“). - `pruefen`: Plan und Manifest müssen übereinstimmen (Reiter ja/nein, Dateien, versprochene Befehle); Warnung, wenn der Prompt bei fehlender Steuerung nichts dazu sagt. - 9 neue Tests (rot ohne die Korrektur), `docs/erste-schritte.md` und SKILL.md angepasst. **Geprüft:** Gesamte Testsuite des Plugins (245 Tests) grün; die neuen Prüfungen schlagen ohne die Änderung an `pd_pruefen.py` fehl. **Nicht geprüft:** Ein ganzer Lauf mit einem neuen Plugin in der App (Grill-me bis Reiter); die Vorlage `panel_api.py` wurde nur auf Syntax geprüft, nicht gegen das echte Kit ausgeführt; der Chat-Weg von `iris-buchhaltung` („leg eine Rechnung an“) ist nicht abschließend bewertet. **Offen:** - Das Modell schreibt Dateien am Werkzeug vorbei (`grill.json` von Hand, installierte Kopie gepatcht): Idee `laden` meldet unbekannte Themenschlüssel. - Aufruflimit 90 Aufrufe je Runde zwingt zu „mach weiter“ (`max_iterations`, Einstellung beim Nutzer). - Bestehende Pläne ohne `seitenpanel` bleiben gültig; ein Plugin mit `side_panel` im Manifest und ohne Eintrag im Plan wird jetzt von `pruefen` beanstandet.
alf commented 2026-10-26 22:46:51 +00:00
Author
Owner
Copy link

Veröffentlicht: Plugin „Plugins entwickeln“ (iris-plugin-dev) 0.1.20

  • Draußen: Version 0.1.20 in der Registry (nach dem Pull geprüft: packages/iris-plugin-dev/iris-plugin-dev-0.1.20.irisplugin).
  • Nutzer bekommen: Das Werkzeug fragt beim Planen eines Plugins nach dem Seitenpanel (Pflichtthema 11), legt Reiter und Befehle im Gerüst an, schreibt dem Agenten im Systemprompt, was er mit dem Reiter darf, und pruefen meldet, wenn Plan und Manifest auseinanderlaufen.
  • Offen: ein ganzer Lauf mit einem neuen Plugin in der App ist nicht ausprobiert (Label bleibt status/zu-testen); Details und Grenzen im Stand-Kommentar oben.
**Veröffentlicht: Plugin „Plugins entwickeln“ (`iris-plugin-dev`) 0.1.20** - Draußen: Version 0.1.20 in der Registry (nach dem Pull geprüft: `packages/iris-plugin-dev/iris-plugin-dev-0.1.20.irisplugin`). - Nutzer bekommen: Das Werkzeug fragt beim Planen eines Plugins nach dem Seitenpanel (Pflichtthema 11), legt Reiter und Befehle im Gerüst an, schreibt dem Agenten im Systemprompt, was er mit dem Reiter darf, und `pruefen` meldet, wenn Plan und Manifest auseinanderlaufen. - Offen: ein ganzer Lauf mit einem neuen Plugin in der App ist nicht ausprobiert (Label bleibt `status/zu-testen`); Details und Grenzen im Stand-Kommentar oben.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
  
herkunft/alpha-feedback
Aus Rückmeldungen der Alpha-Tester

  
status
blockiert
 Wartet auf etwas anderes

  
status
zu-testen
 Gebaut, aber noch nicht im echten Einsatz geprüft

  
typ
bug
 Fehler

  
typ
docs
 Dokumentation

  
typ
enhancement
 Verbesserung einer vorhandenen Funktion

  
typ
feature
 Neue Funktion

  
typ
idea
 Idee, noch nicht entschieden

No labels
herkunft/alpha-feedback
status
blockiert
status
zu-testen
typ
bug
typ
docs
typ
enhancement
typ
feature
typ
idea
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
iris/iris-plugins#171
No description provided.