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

Plugin „iris-plugin-dev“: Plugins von der Idee bis zur Veröffentlichung entwickeln (State Machine) #99

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

Warum

Ein Plugin von der Idee bis in die Registry zu bringen ist ein langer, mechanischer Weg (Manifest, Kategorie, Build-Skript, Skills, store/, Version, Dry-Run, Veröffentlichen, Issue und Stand je PR). Ein LLM neigt dazu, aus einer vagen Idee sofort zu bauen und zu veröffentlichen, und lässt dabei Pflichtfelder, Namenskollisionen, Datenschutz in Store-Material oder den Praxistest aus. Das Plugin iris-plugin-dev führt den Autor deshalb durch feste Stufen, schaltet sie erst nach Belegen oder Freigabe frei und erledigt alles Mechanische per Skript, damit der Kontext des LLM klein bleibt.

Entscheidungen (grill-me, 2026-10-16)

  • Umfang: nur neue Iris-Plugins (.irisplugin). Änderungen an bestehenden Plugins sind ein zweites Profil derselben State Machine (Version 2).
  • Stufen: Idee → Grill-me → Plan → Gerüst im Workspace des Chats (noch ohne Git); danach Repo anlegen → Umsetzung → Geprüft → Store-Material → Veröffentlicht.
  • Freigaben nur vom Nutzer (Wortlaut und Zeitstempel im Zustand): „Grill-me fertig“, „Plan passt“, „Veröffentliche“. Alles dazwischen schaltet das Skript aus Belegen frei (Build, Dry-Run, Tests, keine TODO-Marker, Datenschutz-Scan). Im Chat lässt sich nicht erzwingen, dass eine Freigabe vom Nutzer kommt; erzwungen werden Reihenfolge und Nachvollziehbarkeit.
  • grill-me mit Pflichtthemen: feste Themenliste (Plattformen, Abhängigkeiten, Einstellungen und Zugangsdaten, Installations-Skripte, Datenschutz, Namenskollisionen, Test); Fragen bleiben frei und einzeln, jede mit Empfehlung und Antwort im Protokoll. Zum Plan geht es erst, wenn jedes Thema beantwortet oder ausdrücklich als „nicht nötig“ markiert ist.
  • Gerüst per Skript sofort nach Plan-Freigabe, noch im Workspace (baubar, Platzhalter mit TODO-Markern). Hermes kann einfache Plugins dort fertig machen; für größere geht der Nutzer in Claude Code mit denselben Befehlen weiter.
  • Repo so früh wie möglich: ab der Plan-Freigabe (Name bekannt) kann „Leg für dieses Plugin ein Repo an“ aufgerufen werden. Ab dann ist das Repo die Quelle der Wahrheit; Alf entwickelt auf jeder Dev-Maschine (VS Code, Claude Code) weiter (AUFTRAG.md, plugin_dev.py --vorhaben <id>, Zustand in .dev/state.json) und nimmt den Chat später zum Prüfen und Veröffentlichen wieder auf (vorhaben holen).
  • Repo anlegen nur gegen Forgejo, per Skript: frischer Klon von iris/iris-plugins, Branch NN-slug, Plugin, Issue (Warum/Wie), PR. Nach jedem PR ein ausführlicher Stand-Kommentar im Issue (ship -r schreibt zusätzlich PR-Link und Commits). Kein Bezug zum lokalen Checkout.
  • Geprüft heißt: Manifest gültig (Pflichtfelder, Name iris-…, keine Skill-Namenskollision), Paket baut, publish-plugins.sh --dry-run sauber, keine TODO-Marker; Tests unter tests/ und grün, wenn der Plan eigene Skripte nennt; dazu ein vom Nutzer bestätigter Praxistest.
  • Doku im Plugin (docs/*.md): Der Chat sagt „Die Doku liegt unter <Pfad>“, statt Regeln zu laden. Der Inhalt zieht aus README Kapitel 15, 19, 20 um; die README verweist nur noch darauf.
  • Zugang: Forgejo-URL, Repo und ein eigenes Token mit engen Rechten (Repository und Issues schreiben, kein Admin) in den Plugin-Einstellungen; nie in Plan, Protokoll oder Issue-Texten.
  • Weitere Festlegungen: ID iris-plugin-dev, Kategorie development, Mac und Linux; Skripte in Python (nur Standardbibliothek); .dev/state.json zieht beim Repo-Anlegen ins Repo mit; Veröffentlichen klont Plugin- und Registry-Repo frisch und nutzt publish-plugins.sh von main (Voraussetzung: gemergter PR); Store-Material (Icon, Kurztext, Store-Seite) ist für „Veröffentlicht“ Pflicht, die custom.md optional, aber vorher auf private Daten gescannt.

Wie

Plan, Stufen, Befehle, Zustandsformat und Bauabschnitte: plugins/iris-plugin-dev/PLAN.md. Die Beschreibung bleibt die Spezifikation; der Verlauf steht in den Kommentaren.

Nicht Teil dieser Version

Änderungen an bestehenden Plugins, Blender-Addons und andere Projektarten.

## Warum Ein Plugin von der Idee bis in die Registry zu bringen ist ein langer, mechanischer Weg (Manifest, Kategorie, Build-Skript, Skills, `store/`, Version, Dry-Run, Veröffentlichen, Issue und Stand je PR). Ein LLM neigt dazu, aus einer vagen Idee sofort zu bauen und zu veröffentlichen, und lässt dabei Pflichtfelder, Namenskollisionen, Datenschutz in Store-Material oder den Praxistest aus. Das Plugin `iris-plugin-dev` führt den Autor deshalb durch feste Stufen, schaltet sie erst nach Belegen oder Freigabe frei und erledigt alles Mechanische per Skript, damit der Kontext des LLM klein bleibt. ## Entscheidungen (grill-me, 2026-10-16) - **Umfang:** nur **neue Iris-Plugins** (`.irisplugin`). Änderungen an bestehenden Plugins sind ein zweites Profil derselben State Machine (Version 2). - **Stufen:** `Idee → Grill-me → Plan → Gerüst` im **Workspace des Chats** (noch ohne Git); danach `Repo anlegen → Umsetzung → Geprüft → Store-Material → Veröffentlicht`. - **Freigaben nur vom Nutzer** (Wortlaut und Zeitstempel im Zustand): „Grill-me fertig“, „Plan passt“, „Veröffentliche“. Alles dazwischen schaltet das Skript aus Belegen frei (Build, Dry-Run, Tests, keine TODO-Marker, Datenschutz-Scan). Im Chat lässt sich nicht erzwingen, dass eine Freigabe vom Nutzer kommt; erzwungen werden Reihenfolge und Nachvollziehbarkeit. - **grill-me mit Pflichtthemen:** feste Themenliste (Plattformen, Abhängigkeiten, Einstellungen und Zugangsdaten, Installations-Skripte, Datenschutz, Namenskollisionen, Test); Fragen bleiben frei und einzeln, jede mit Empfehlung und Antwort im Protokoll. Zum Plan geht es erst, wenn jedes Thema beantwortet oder ausdrücklich als „nicht nötig“ markiert ist. - **Gerüst per Skript** sofort nach Plan-Freigabe, noch im Workspace (baubar, Platzhalter mit TODO-Markern). Hermes kann einfache Plugins dort fertig machen; für größere geht der Nutzer in Claude Code mit denselben Befehlen weiter. - **Repo so früh wie möglich:** ab der Plan-Freigabe (Name bekannt) kann „Leg für dieses Plugin ein Repo an“ aufgerufen werden. Ab dann ist das Repo die Quelle der Wahrheit; Alf entwickelt auf jeder Dev-Maschine (VS Code, Claude Code) weiter (`AUFTRAG.md`, `plugin_dev.py --vorhaben <id>`, Zustand in `.dev/state.json`) und nimmt den Chat später zum Prüfen und Veröffentlichen wieder auf (`vorhaben holen`). - **Repo anlegen nur gegen Forgejo**, per Skript: frischer Klon von `iris/iris-plugins`, Branch `NN-slug`, Plugin, Issue (Warum/Wie), PR. Nach jedem PR ein ausführlicher Stand-Kommentar im Issue (`ship -r` schreibt zusätzlich PR-Link und Commits). Kein Bezug zum lokalen Checkout. - **Geprüft** heißt: Manifest gültig (Pflichtfelder, Name `iris-…`, keine Skill-Namenskollision), Paket baut, `publish-plugins.sh --dry-run` sauber, keine TODO-Marker; Tests unter `tests/` und grün, wenn der Plan eigene Skripte nennt; dazu ein vom Nutzer bestätigter Praxistest. - **Doku im Plugin** (`docs/*.md`): Der Chat sagt „Die Doku liegt unter `<Pfad>`“, statt Regeln zu laden. Der Inhalt zieht aus README Kapitel 15, 19, 20 um; die README verweist nur noch darauf. - **Zugang:** Forgejo-URL, Repo und ein eigenes Token mit engen Rechten (Repository und Issues schreiben, kein Admin) in den Plugin-Einstellungen; nie in Plan, Protokoll oder Issue-Texten. - **Weitere Festlegungen:** ID `iris-plugin-dev`, Kategorie `development`, Mac und Linux; Skripte in Python (nur Standardbibliothek); `.dev/state.json` zieht beim Repo-Anlegen ins Repo mit; Veröffentlichen klont Plugin- und Registry-Repo frisch und nutzt `publish-plugins.sh` von `main` (Voraussetzung: gemergter PR); Store-Material (Icon, Kurztext, Store-Seite) ist für „Veröffentlicht“ Pflicht, die `custom.md` optional, aber vorher auf private Daten gescannt. ## Wie Plan, Stufen, Befehle, Zustandsformat und Bauabschnitte: `plugins/iris-plugin-dev/PLAN.md`. Die Beschreibung bleibt die Spezifikation; der Verlauf steht in den Kommentaren. ## Nicht Teil dieser Version Änderungen an bestehenden Plugins, Blender-Addons und andere Projektarten.
alf commented 2026-10-16 20:38:58 +00:00
Author
Owner
Copy link

PR #100 gemergt: docs(plugin-dev): Plan für das Plugin iris-plugin-dev (State Machine) (#99)
#100

Commits:

  • docs(plugin-dev): Plan für das Plugin iris-plugin-dev (State Machine) (#99)
PR #100 gemergt: docs(plugin-dev): Plan für das Plugin iris-plugin-dev (State Machine) (#99) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/100 Commits: - docs(plugin-dev): Plan für das Plugin iris-plugin-dev (State Machine) (#99)
alf commented 2026-10-16 20:40:21 +00:00
Author
Owner
Copy link

Stand: Plan steht (2026-10-16)

Plan eingereicht (plugins/iris-plugin-dev/PLAN.md, e8fe101): Stufen, Befehle, Zustandsformat, Pflichtthemen, Gerüst, Repo anlegen, Veröffentlichen, Datenschutz-Scan, Bauabschnitte 1–8. Noch nichts gebaut. Offen: Lage und Lebensdauer des Chat-Workspaces; ob Hermes das Token aus den Plugin-Einstellungen zuverlässig an das Skript reicht; Praxistest bei reinen Skill-Plugins (nur Wortlaut als Beleg). Nächster Schritt: Abschnitt 1 (Kern mit Zustand und Stufentabelle).

## Stand: Plan steht (2026-10-16) Plan eingereicht (`plugins/iris-plugin-dev/PLAN.md`, `e8fe101`): Stufen, Befehle, Zustandsformat, Pflichtthemen, Gerüst, Repo anlegen, Veröffentlichen, Datenschutz-Scan, Bauabschnitte 1–8. Noch nichts gebaut. Offen: Lage und Lebensdauer des Chat-Workspaces; ob Hermes das Token aus den Plugin-Einstellungen zuverlässig an das Skript reicht; Praxistest bei reinen Skill-Plugins (nur Wortlaut als Beleg). Nächster Schritt: Abschnitt 1 (Kern mit Zustand und Stufentabelle).
alf commented 2026-10-16 20:48:39 +00:00
Author
Owner
Copy link

PR #101 gemergt: docs(plugin-dev): Repo ab Plan-Freigabe, Weiterarbeiten auf der Dev-Maschine (#99)
#101

Commits:

  • docs(plugin-dev): Repo ab Plan-Freigabe, Weiterarbeiten auf der Dev-Maschine (#99)
PR #101 gemergt: docs(plugin-dev): Repo ab Plan-Freigabe, Weiterarbeiten auf der Dev-Maschine (#99) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/101 Commits: - docs(plugin-dev): Repo ab Plan-Freigabe, Weiterarbeiten auf der Dev-Maschine (#99)
alf commented 2026-10-16 20:52:25 +00:00
Author
Owner
Copy link

Änderung am Plan: Repo früh, Weiterarbeiten außerhalb des Chats

Auf Alfs Wunsch: „Leg für dieses Plugin ein Repo an“ geht ab der Plan-Freigabe (Gerüst entsteht dabei gleich). Das Repo ist danach die Quelle der Wahrheit; Umsetzung, Prüfung und Store-Material laufen in VS Code/Claude Code auf einer Dev-Maschine (AUFTRAG.md aus dem Plan, plugin_dev.py --vorhaben <id>, Belege mit Fingerabdruck in .dev/state.json), der Chat wird zum Prüfen/Stand/Veröffentlichen mit vorhaben holen wieder aufgenommen. Bauabschnitt „Forgejo“ rückt auf Platz 4 vor. Offen neu: Zusammenführen des Zustands, wenn Chat und Dev-Maschine gleichzeitig Belege schreiben (Entwurf: Fingerabdruck entscheidet).

## Änderung am Plan: Repo früh, Weiterarbeiten außerhalb des Chats Auf Alfs Wunsch: „Leg für dieses Plugin ein Repo an“ geht ab der Plan-Freigabe (Gerüst entsteht dabei gleich). Das Repo ist danach die Quelle der Wahrheit; Umsetzung, Prüfung und Store-Material laufen in VS Code/Claude Code auf einer Dev-Maschine (`AUFTRAG.md` aus dem Plan, `plugin_dev.py --vorhaben <id>`, Belege mit Fingerabdruck in `.dev/state.json`), der Chat wird zum Prüfen/Stand/Veröffentlichen mit `vorhaben holen` wieder aufgenommen. Bauabschnitt „Forgejo“ rückt auf Platz 4 vor. Offen neu: Zusammenführen des Zustands, wenn Chat und Dev-Maschine gleichzeitig Belege schreiben (Entwurf: Fingerabdruck entscheidet).
alf commented 2026-10-16 21:05:09 +00:00
Author
Owner
Copy link

PR #102 gemergt: feat(plugin-dev): Kern — Zustand, Stufentabelle, Fingerabdrücke, neu/status/doku (#99)
#102

Commits:

  • feat(plugin-dev): Kern — Zustand, Stufentabelle, Fingerabdrücke, neu/status/doku (#99)
PR #102 gemergt: feat(plugin-dev): Kern — Zustand, Stufentabelle, Fingerabdrücke, neu/status/doku (#99) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/102 Commits: - feat(plugin-dev): Kern — Zustand, Stufentabelle, Fingerabdrücke, neu/status/doku (#99)
alf commented 2026-10-16 21:06:33 +00:00
Author
Owner
Copy link

PR #103 gemergt: feat(plugin-dev): grill-me — Pflichtthemen, Protokoll, Freigabe; Kern in eigenes Modul (#99)
#103

Commits:

  • feat(plugin-dev): grill-me — Pflichtthemen, Protokoll, Freigabe; Kern in eigenes Modul (#99)
PR #103 gemergt: feat(plugin-dev): grill-me — Pflichtthemen, Protokoll, Freigabe; Kern in eigenes Modul (#99) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/103 Commits: - feat(plugin-dev): grill-me — Pflichtthemen, Protokoll, Freigabe; Kern in eigenes Modul (#99)
alf commented 2026-10-16 21:07:48 +00:00
Author
Owner
Copy link

Stand: Bauabschnitte 1 und 2 (2026-10-16)

Kern (e79bda3) und grill-me (PR folgt oben): skills/iris-plugin-dev/ mit plugin_dev.py (CLI), pd_kern.py (Zustand, Stufentabelle als Daten, Fingerabdrücke) und pd_grill.py. Die Stufe wird nie gespeichert, sondern aus Zustand und Dateien berechnet; eine Freigabe oder ein Beleg gilt nur, solange der Fingerabdruck seines Bereichs (grill, plan, paket, code, store) derselbe ist. Es gibt keinen allgemeinen Befehl „Freigabe setzen“; Freigaben entstehen nur in ihrer Stufe und nur, wenn alle früheren gelten (Praxistest zusätzlich erst nach dem Prüfbeleg).
grill-me: 9 Pflichtthemen, Protokoll .dev/grill.json, zweck und name nicht überspringbar, „nicht nötig“ nur mit Grund, grill fertig erst ohne offenes Thema.
Geprüft: 31 Tests grün (python3 -m unittest discover -s tests in iris-plugin-dev/), CLI mit python3 -I von Hand gelaufen (neu, status, doku). Grenzen: noch kein plan, kein Gerüst, kein Forgejo; status kennzeichnet noch nicht gebaute Befehle. Als Nächstes: Abschnitt 3 (Plan und Gerüst).

## Stand: Bauabschnitte 1 und 2 (2026-10-16) **Kern** (`e79bda3`) und **grill-me** (PR folgt oben): `skills/iris-plugin-dev/` mit `plugin_dev.py` (CLI), `pd_kern.py` (Zustand, Stufentabelle als Daten, Fingerabdrücke) und `pd_grill.py`. Die Stufe wird nie gespeichert, sondern aus Zustand und Dateien berechnet; eine Freigabe oder ein Beleg gilt nur, solange der Fingerabdruck seines Bereichs (grill, plan, paket, code, store) derselbe ist. Es gibt keinen allgemeinen Befehl „Freigabe setzen“; Freigaben entstehen nur in ihrer Stufe und nur, wenn alle früheren gelten (Praxistest zusätzlich erst nach dem Prüfbeleg). grill-me: 9 Pflichtthemen, Protokoll `.dev/grill.json`, `zweck` und `name` nicht überspringbar, „nicht nötig“ nur mit Grund, `grill fertig` erst ohne offenes Thema. **Geprüft:** 31 Tests grün (`python3 -m unittest discover -s tests` in `iris-plugin-dev/`), CLI mit `python3 -I` von Hand gelaufen (`neu`, `status`, `doku`). **Grenzen:** noch kein `plan`, kein Gerüst, kein Forgejo; `status` kennzeichnet noch nicht gebaute Befehle. **Als Nächstes:** Abschnitt 3 (Plan und Gerüst).
alf commented 2026-10-16 21:10:58 +00:00
Author
Owner
Copy link

PR #104 gemergt: feat(plugin-dev): Plan prüfen/speichern/freigeben und baubares Gerüst aus plan.json (#99)
#104

Commits:

  • feat(plugin-dev): Plan prüfen/speichern/freigeben und baubares Gerüst aus plan.json (#99)
PR #104 gemergt: feat(plugin-dev): Plan prüfen/speichern/freigeben und baubares Gerüst aus plan.json (#99) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/104 Commits: - feat(plugin-dev): Plan prüfen/speichern/freigeben und baubares Gerüst aus plan.json (#99)
alf commented 2026-10-16 21:21:35 +00:00
Author
Owner
Copy link

PR #105 gemergt: feat(plugin-dev): Forgejo — Repo anlegen (Issue, Branch, PR), Klon als Quelle der Wahrheit, senden, holen, Stand-Kommentar (#99)
#105

Commits:

  • feat(plugin-dev): Forgejo — Repo anlegen (Issue, Branch, PR), Klon als Quelle der Wahrheit, senden, holen, Stand-Kommentar (#99)
PR #105 gemergt: feat(plugin-dev): Forgejo — Repo anlegen (Issue, Branch, PR), Klon als Quelle der Wahrheit, senden, holen, Stand-Kommentar (#99) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/105 Commits: - feat(plugin-dev): Forgejo — Repo anlegen (Issue, Branch, PR), Klon als Quelle der Wahrheit, senden, holen, Stand-Kommentar (#99)
alf commented 2026-10-16 21:23:49 +00:00
Author
Owner
Copy link

Stand: Bauabschnitt 3 und 4 (2026-10-16)

Plan und Gerüst (ad9d28a): plan vorlage, plan setzen (nur nach grill-me; prüft Pflichtfelder, unbekannte Felder, Plattformen, Skill-Namen gegen installierte Hermes-Skills, Kategorie, requires und ID-Kollision gegen die echte Registry; ungültig = nichts geschrieben), plan freigeben (erzeugt gleich das Gerüst: plugin.json, Build-Skript, SKILL.md-Stubs, Skript- und Test-Stubs, store-page.json, Hooks; TODO:-Marker, Test-Stubs schlagen fehl; das Gerüst baut; vorhandene Dateien werden nie überschrieben).
Forgejo (b009de6): repo anlegen ab Plan-Freigabe: Issue (Warum, Entscheidungen aus grill-me, Wie, Nicht Teil) → Branch NN-<id> → Plugin samt .dev/, PLAN.md, AUFTRAG.md → PR; main bleibt unberührt. Danach ist der Klon die Quelle der Wahrheit (Umzugsvermerk im Workspace). Dazu repo senden, repo stand, vorhaben-holen, stand-kommentar. Das Token geht nur über Umgebungsvariablen an git und wird nie ausgegeben.
Geprüft: 63 Tests grün (u. a. Fake-Forgejo mit lokalem Bare-Repo, Wiederaufnahme nach Abbruch, Token nie in Dateien oder Ausgaben). Echtlauf mit python3 -I gegen ein Wegwerf-Repo auf dem eigenen Forgejo (Issue, Branch, PR, Kommentar, PR-Stand), danach gelöscht; auch der Plan-Check gegen die echte Registry lief. Grenzen: Einstellungen noch nur per Umgebung/Datei (Web-View folgt); noch kein pruefen, store, veroeffentlichen, Skill und Doku. Als Nächstes: Abschnitt 5 (Prüfen).

## Stand: Bauabschnitt 3 und 4 (2026-10-16) **Plan und Gerüst** (`ad9d28a`): `plan vorlage`, `plan setzen` (nur nach grill-me; prüft Pflichtfelder, unbekannte Felder, Plattformen, Skill-Namen gegen installierte Hermes-Skills, Kategorie, `requires` und ID-Kollision gegen die echte Registry; ungültig = nichts geschrieben), `plan freigeben` (erzeugt gleich das Gerüst: `plugin.json`, Build-Skript, `SKILL.md`-Stubs, Skript- und Test-Stubs, `store-page.json`, Hooks; `TODO:`-Marker, Test-Stubs schlagen fehl; das Gerüst baut; vorhandene Dateien werden nie überschrieben). **Forgejo** (`b009de6`): `repo anlegen` ab Plan-Freigabe: Issue (Warum, Entscheidungen aus grill-me, Wie, Nicht Teil) → Branch `NN-<id>` → Plugin samt `.dev/`, `PLAN.md`, `AUFTRAG.md` → PR; `main` bleibt unberührt. Danach ist der Klon die Quelle der Wahrheit (Umzugsvermerk im Workspace). Dazu `repo senden`, `repo stand`, `vorhaben-holen`, `stand-kommentar`. Das Token geht nur über Umgebungsvariablen an git und wird nie ausgegeben. **Geprüft:** 63 Tests grün (u. a. Fake-Forgejo mit lokalem Bare-Repo, Wiederaufnahme nach Abbruch, Token nie in Dateien oder Ausgaben). Echtlauf mit `python3 -I` gegen ein Wegwerf-Repo auf dem eigenen Forgejo (Issue, Branch, PR, Kommentar, PR-Stand), danach gelöscht; auch der Plan-Check gegen die echte Registry lief. **Grenzen:** Einstellungen noch nur per Umgebung/Datei (Web-View folgt); noch kein `pruefen`, `store`, `veroeffentlichen`, Skill und Doku. **Als Nächstes:** Abschnitt 5 (Prüfen).
alf commented 2026-10-16 21:25:33 +00:00
Author
Owner
Copy link

PR #106 gemergt: feat(plugin-dev): pruefen — TODO-Marker, Tests, Manifest gegen Plan und Registry, Build, Praxistest (#99)
#106

Commits:

  • feat(plugin-dev): pruefen — TODO-Marker, Tests, Manifest gegen Plan und Registry, Build, Praxistest (#99)
PR #106 gemergt: feat(plugin-dev): pruefen — TODO-Marker, Tests, Manifest gegen Plan und Registry, Build, Praxistest (#99) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/106 Commits: - feat(plugin-dev): pruefen — TODO-Marker, Tests, Manifest gegen Plan und Registry, Build, Praxistest (#99)
alf commented 2026-10-16 21:28:35 +00:00
Author
Owner
Copy link

PR #107 gemergt: feat(plugin-dev): Store — Seite und Icon erzeugen, Datenschutz-Scan, Dry-Run, Bilder bestätigen (#99)
#107

Commits:

  • feat(plugin-dev): Store — Seite und Icon erzeugen, Datenschutz-Scan, Dry-Run, Bilder bestätigen (#99)
PR #107 gemergt: feat(plugin-dev): Store — Seite und Icon erzeugen, Datenschutz-Scan, Dry-Run, Bilder bestätigen (#99) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/107 Commits: - feat(plugin-dev): Store — Seite und Icon erzeugen, Datenschutz-Scan, Dry-Run, Bilder bestätigen (#99)
alf commented 2026-10-16 21:32:06 +00:00
Author
Owner
Copy link

PR #108 gemergt: feat(plugin-dev): Veröffentlichen — gemergter PR, freigegebener Stand, Dry-Run, Push, Prüfung (#99)
#108

Commits:

  • feat(plugin-dev): Veröffentlichen — gemergter PR, freigegebener Stand, Dry-Run, Push, Prüfung (#99)
PR #108 gemergt: feat(plugin-dev): Veröffentlichen — gemergter PR, freigegebener Stand, Dry-Run, Push, Prüfung (#99) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/108 Commits: - feat(plugin-dev): Veröffentlichen — gemergter PR, freigegebener Stand, Dry-Run, Push, Prüfung (#99)
alf commented 2026-10-16 21:33:09 +00:00
Author
Owner
Copy link

PR #109 gemergt: test(plugin-dev): Kern-Test an die Freigabe in der Stufe Veröffentlicht angepasst (#99)
#109

Commits:

  • test(plugin-dev): Kern-Test an die Freigabe in der Stufe Veröffentlicht angepasst (#99)
PR #109 gemergt: test(plugin-dev): Kern-Test an die Freigabe in der Stufe Veröffentlicht angepasst (#99) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/109 Commits: - test(plugin-dev): Kern-Test an die Freigabe in der Stufe Veröffentlicht angepasst (#99)
alf commented 2026-10-16 21:41:55 +00:00
Author
Owner
Copy link

PR #110 gemergt: feat(plugin-dev): Plugin-Paket — Skill, Einstellungs-Panel, Doku aus der README, Build; Linux-Test (#99)
#110

Commits:

  • feat(plugin-dev): Plugin-Paket — Skill, Einstellungs-Panel, Doku aus der README, Build; Linux-Test (#99)
PR #110 gemergt: feat(plugin-dev): Plugin-Paket — Skill, Einstellungs-Panel, Doku aus der README, Build; Linux-Test (#99) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/110 Commits: - feat(plugin-dev): Plugin-Paket — Skill, Einstellungs-Panel, Doku aus der README, Build; Linux-Test (#99)
alf commented 2026-10-16 21:42:51 +00:00
Author
Owner
Copy link

Stand: alle acht Bauabschnitte gebaut (2026-10-16)

Gebaut (PRs bis 1a05a95): Kern mit Stufentabelle und Fingerabdrücken, grill-me mit 9 Pflichtthemen, Plan und baubares Gerüst, Forgejo (Repo früh anlegen, Klon als Quelle der Wahrheit, senden, holen, Stand-Kommentar), Prüfen (TODO-Marker, Tests, Manifest gegen Plan und Registry, Build, Praxistest), Store (Seite und Icon erzeugen, Datenschutz-Scan, Dry-Run, Bilder bestätigen lassen), Veröffentlichen (nur gemergter PR, nur freigegebener Stand, Dry-Run, Push, Prüfung), Plugin-Paket mit Skill, Einstellungs-Panel und Doku. Die Doku (docs/) wird beim Bauen aus den README-Kapiteln erzeugt, die README bleibt die einzige Quelle.
Geprüft: 107 Tests grün (python3 -m unittest discover -s tests in iris-plugin-dev/), darunter Fake-Forgejo mit Bare-Repos, der echte publish-plugins.sh-Dry-Run und ein echtes Veröffentlichen in eine Wegwerf-Registry. Echtlauf auf dem eigenen Forgejo gegen ein Wegwerf-Repo (Issue, Branch, PR, Kommentar, PR-Stand; danach gelöscht). Linux-Test auf iris-server (Drop-Zone): Plugin installiert, Skill läuft im Hermes-Container, das Panel läuft über /plugins/iris-plugin-dev/api/*, und die vom Panel gespeicherten Einstellungen liest der Skill im Hermes-Container (gemeinsames Verzeichnis iris-app-support; das war die offene Frage zum Token); danach vollständig entfernt.
Grenzen / noch nicht getan: das Plugin selbst ist nicht veröffentlicht (.include, Store-Seite, Version fehlen bewusst; Veröffentlichen nur auf Alfs Wort); kein Test in der echten Mac-Iris; das echte Veröffentlichen in die echte Registry wurde nie ausgeführt (nur gegen Wegwerf-Registry); der Zustand „veröffentlicht“ liegt nur lokal und geht mit dem nächsten repo senden ins Repo. Offen aus dem Plan: Zusammenführen des Zustands, wenn Chat und Dev-Maschine gleichzeitig Belege schreiben (Fingerabdruck entscheidet, im Zweifel neu prüfen).
Als Nächstes: auf dem Mac installieren und mit einem echten Mini-Plugin einmal durchspielen (bis einschließlich „Repo anlegen“ gegen iris/iris-plugins); danach iris-plugin-dev selbst store-tauglich machen und veröffentlichen.

## Stand: alle acht Bauabschnitte gebaut (2026-10-16) **Gebaut** (PRs bis `1a05a95`): Kern mit Stufentabelle und Fingerabdrücken, grill-me mit 9 Pflichtthemen, Plan und baubares Gerüst, Forgejo (Repo früh anlegen, Klon als Quelle der Wahrheit, senden, holen, Stand-Kommentar), Prüfen (TODO-Marker, Tests, Manifest gegen Plan und Registry, Build, Praxistest), Store (Seite und Icon erzeugen, Datenschutz-Scan, Dry-Run, Bilder bestätigen lassen), Veröffentlichen (nur gemergter PR, nur freigegebener Stand, Dry-Run, Push, Prüfung), Plugin-Paket mit Skill, Einstellungs-Panel und Doku. Die Doku (`docs/`) wird beim Bauen aus den README-Kapiteln erzeugt, die README bleibt die einzige Quelle. **Geprüft:** 107 Tests grün (`python3 -m unittest discover -s tests` in `iris-plugin-dev/`), darunter Fake-Forgejo mit Bare-Repos, der echte `publish-plugins.sh`-Dry-Run und ein echtes Veröffentlichen in eine Wegwerf-Registry. **Echtlauf auf dem eigenen Forgejo** gegen ein Wegwerf-Repo (Issue, Branch, PR, Kommentar, PR-Stand; danach gelöscht). **Linux-Test auf `iris-server`** (Drop-Zone): Plugin installiert, Skill läuft im Hermes-Container, das Panel läuft über `/plugins/iris-plugin-dev/api/*`, und die vom Panel gespeicherten Einstellungen liest der Skill im Hermes-Container (gemeinsames Verzeichnis `iris-app-support`; das war die offene Frage zum Token); danach vollständig entfernt. **Grenzen / noch nicht getan:** das Plugin selbst ist nicht veröffentlicht (`.include`, Store-Seite, Version fehlen bewusst; Veröffentlichen nur auf Alfs Wort); kein Test in der echten Mac-Iris; das echte Veröffentlichen in die echte Registry wurde nie ausgeführt (nur gegen Wegwerf-Registry); der Zustand „veröffentlicht“ liegt nur lokal und geht mit dem nächsten `repo senden` ins Repo. Offen aus dem Plan: Zusammenführen des Zustands, wenn Chat und Dev-Maschine gleichzeitig Belege schreiben (Fingerabdruck entscheidet, im Zweifel neu prüfen). **Als Nächstes:** auf dem Mac installieren und mit einem echten Mini-Plugin einmal durchspielen (bis einschließlich „Repo anlegen“ gegen `iris/iris-plugins`); danach `iris-plugin-dev` selbst store-tauglich machen und veröffentlichen.
alf commented 2026-10-16 21:45:39 +00:00
Author
Owner
Copy link

PR #111 gemergt: feat(plugin-dev): Store-Material (Seite, Icon, Langtext) und .include zum Veröffentlichen (#99)
#111

Commits:

  • feat(plugin-dev): Store-Material (Seite, Icon, Langtext) und .include zum Veröffentlichen (#99)
PR #111 gemergt: feat(plugin-dev): Store-Material (Seite, Icon, Langtext) und .include zum Veröffentlichen (#99) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/111 Commits: - feat(plugin-dev): Store-Material (Seite, Icon, Langtext) und .include zum Veröffentlichen (#99)
alf commented 2026-10-16 21:46:27 +00:00
Author
Owner
Copy link

Veröffentlicht: iris-plugin-dev 0.1.0 (2026-10-16)

Auf Alfs ausdrückliches „Veröffentliche das Plugin“. Ergänzt: Store-Seite, Icon, Langtext, .include (dd25cfe, PR gemergt). Vorher: Datenschutz-Scan der Store-Texte und der beim Bauen aus der README erzeugten Doku (nur Beispielcode als Fehlalarm), Dry-Run sauber. Dann ./publish-plugins.sh iris-plugin-dev aus main: Registry-Commit 51c56de; der Index auf Forgejo trägt iris-plugin-dev 0.1.0 (Kategorie development, Mac und Linux, 3 Store-Dateien; die Registry hat jetzt 21 Plugins). Veröffentlicht wurde von Hand mit publish-plugins.sh, nicht mit dem Befehl veroeffentlichen des Plugins (das Plugin selbst ist kein Vorhaben mit Zustand).
Noch nicht getan: Mac-Test in der echten Iris, erster echter Einsatz mit einem Mini-Plugin. Das Issue bleibt offen.

## Veröffentlicht: iris-plugin-dev 0.1.0 (2026-10-16) Auf Alfs ausdrückliches „Veröffentliche das Plugin“. Ergänzt: Store-Seite, Icon, Langtext, `.include` (`dd25cfe`, PR gemergt). Vorher: Datenschutz-Scan der Store-Texte und der beim Bauen aus der README erzeugten Doku (nur Beispielcode als Fehlalarm), Dry-Run sauber. Dann `./publish-plugins.sh iris-plugin-dev` aus `main`: Registry-Commit `51c56de`; der Index auf Forgejo trägt `iris-plugin-dev` 0.1.0 (Kategorie development, Mac und Linux, 3 Store-Dateien; die Registry hat jetzt 21 Plugins). Veröffentlicht wurde von Hand mit `publish-plugins.sh`, nicht mit dem Befehl `veroeffentlichen` des Plugins (das Plugin selbst ist kein Vorhaben mit Zustand). **Noch nicht getan:** Mac-Test in der echten Iris, erster echter Einsatz mit einem Mini-Plugin. Das Issue bleibt offen.
alf commented 2026-10-16 21:46:30 +00:00
Author
Owner
Copy link

PR #112 gemergt: docs(plugin-dev): iris-plugin-dev 0.1.0 veröffentlicht, Plan aktualisiert (#99)
#112

Commits:

  • docs(plugin-dev): iris-plugin-dev 0.1.0 veröffentlicht, Plan aktualisiert (#99)
PR #112 gemergt: docs(plugin-dev): iris-plugin-dev 0.1.0 veröffentlicht, Plan aktualisiert (#99) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/112 Commits: - docs(plugin-dev): iris-plugin-dev 0.1.0 veröffentlicht, Plan aktualisiert (#99)
alf commented 2026-10-21 21:55:23 +00:00
Author
Owner
Copy link

Abgeschlossen

iris-plugin-dev ist veröffentlicht (0.1.0 am 2026-10-16, aktuell 0.1.12) und im Einsatz: Damit entstand iris-claude-sessions. Weitere Verbesserungen laufen in iris/iris-plugins#171, die Anleitung des Plugins ist Teil von #194.

Geschlossen auf Alfs ausdrückliches Wort (2026-10-21).

## Abgeschlossen iris-plugin-dev ist veröffentlicht (0.1.0 am 2026-10-16, aktuell 0.1.12) und im Einsatz: Damit entstand iris-claude-sessions. Weitere Verbesserungen laufen in iris/iris-plugins#171, die Anleitung des Plugins ist Teil von #194. Geschlossen auf Alfs ausdrückliches Wort (2026-10-21).
alf closed this issue 2026-10-21 21:55:23 +00:00
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#99
No description provided.