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

comfyui-workflows 3.3.0: Starter für die Workflow-Verwaltung — autonomer Block ohne Modell-Lauf (iris/Iris#149) #248

New issue
Closed
opened 2026-10-24 15:02:16 +00:00 by alf · 2 comments
alf commented 2026-10-24 15:02:16 +00:00
Owner
Copy link

Ziel

Das erste veröffentlichte Plugin, das die autonomen Web-Blöcke (iris/Iris#149) wirklich nutzt: Die Verwaltungs-GUI von comfyui-workflows lässt sich per Starter direkt in den Chat legen — ohne Chat-Modell, ohne show_canvas-Umweg — und der Block bleibt bedienbar, auch wenn später neue Canvas im Chat erscheinen.

Warum

Der Block comfyui_workflow_manager existiert seit 3.0.0, aber ihn zu öffnen kostet bisher einen Modell-Lauf (Flow 8 im Skill: der Nutzer muss etwas sagen, Hermes zeigt den Canvas). Mit launchers im Manifest erscheint der Starter auf der Plugin-Karte und in der Chat-Leiste; ein Klick führt die Aktion oeffnen aus und hängt den Block ohne Lauf an.

Zu tun

  • actions/oeffnen.py (neuer Ordner actions/ — das Skript-Paket umfasst den ganzen Skript-Ordner, in scripts/ würde die 79-KB-Registry mit in den Client-Cache wandern): gibt {"block": {"type": "comfyui_workflow_manager", …}} zurück, nur Standardbibliothek.
  • Manifest: actions_api: 1, autonomous_block_types: ["comfyui_workflow_manager"], actions.oeffnen, launchers (id workflow-manager), changelog-Feld, Version 3.3.0.
  • Store-Material: store/changelog.md neuer Abschnitt, store-page.json (Starter als Feature/Beispiel), docs/erste-schritte.md.
  • PLAN.md und Daily Log.

Grenzen

  • Nur Starter, keine Vollmigration. Die Registry-Routen (/plugins/comfyui-workflows/registry/..., fetch + cfg_token) bleiben, wie sie sind: Die Workflow-Bibliothek liegt auf dem Server, der Block funktioniert bewusst auch im IrisClient gegen einen entfernten Server — irisCall-Aktionen würden auf dem Client-Gerät gegen dessen eigene, leere Bibliothek laufen. Kein irisSaveState (der Bridge-Script steckt in CanvasWorkflowManagerBlockView/PinnedWebView bisher nicht).
  • Gegen einen Linux-Server verbunden funktioniert der Starter erst mit iris-linux-server#91 (Route /plugins/<id>/actions, launchers in der Plugin-Liste). Auf dem Mac (lokaler Server) läuft er ab Iris 2.0.1.
  • Der Block wird durch autonomous_block_types nicht mehr von neueren Canvas abgelöst und bekommt nie einen „Absenden“-Knopf (war er über selfContainedPluginBlockTypes schon vorher nicht).

Abnahme

  • Starter-Klick auf der Plugin-Karte und in der Chat-Leiste legt den Block in den Chat; im Hermes-Log kein Lauf.
  • Nach zehn weiteren Canvas im Chat ist der Block noch bedienbar.
  • publish-plugins.sh-Prüfung (Manifest-Validierung, Datenschutz-Scan) besteht; Veröffentlichung über --dry-run dann real.
## Ziel Das erste veröffentlichte Plugin, das die autonomen Web-Blöcke (iris/Iris#149) wirklich nutzt: Die Verwaltungs-GUI von comfyui-workflows lässt sich per **Starter** direkt in den Chat legen — ohne Chat-Modell, ohne `show_canvas`-Umweg — und der Block bleibt bedienbar, auch wenn später neue Canvas im Chat erscheinen. ## Warum Der Block `comfyui_workflow_manager` existiert seit 3.0.0, aber ihn zu öffnen kostet bisher einen Modell-Lauf (Flow 8 im Skill: der Nutzer muss etwas sagen, Hermes zeigt den Canvas). Mit `launchers` im Manifest erscheint der Starter auf der Plugin-Karte und in der Chat-Leiste; ein Klick führt die Aktion `oeffnen` aus und hängt den Block ohne Lauf an. ## Zu tun - `actions/oeffnen.py` (neuer Ordner `actions/` — das Skript-Paket umfasst den ganzen Skript-Ordner, in `scripts/` würde die 79-KB-Registry mit in den Client-Cache wandern): gibt `{"block": {"type": "comfyui_workflow_manager", …}}` zurück, nur Standardbibliothek. - Manifest: `actions_api: 1`, `autonomous_block_types: ["comfyui_workflow_manager"]`, `actions.oeffnen`, `launchers` (id `workflow-manager`), `changelog`-Feld, Version 3.3.0. - Store-Material: `store/changelog.md` neuer Abschnitt, `store-page.json` (Starter als Feature/Beispiel), `docs/erste-schritte.md`. - `PLAN.md` und Daily Log. ## Grenzen - **Nur Starter, keine Vollmigration.** Die Registry-Routen (`/plugins/comfyui-workflows/registry/...`, fetch + cfg_token) bleiben, wie sie sind: Die Workflow-Bibliothek liegt auf dem **Server**, der Block funktioniert bewusst auch im IrisClient gegen einen entfernten Server — `irisCall`-Aktionen würden auf dem Client-Gerät gegen dessen eigene, leere Bibliothek laufen. Kein `irisSaveState` (der Bridge-Script steckt in `CanvasWorkflowManagerBlockView`/`PinnedWebView` bisher nicht). - Gegen einen **Linux-Server** verbunden funktioniert der Starter erst mit iris-linux-server#91 (Route `/plugins/<id>/actions`, `launchers` in der Plugin-Liste). Auf dem Mac (lokaler Server) läuft er ab Iris 2.0.1. - Der Block wird durch `autonomous_block_types` nicht mehr von neueren Canvas abgelöst und bekommt nie einen „Absenden“-Knopf (war er über `selfContainedPluginBlockTypes` schon vorher nicht). ## Abnahme - Starter-Klick auf der Plugin-Karte und in der Chat-Leiste legt den Block in den Chat; im Hermes-Log kein Lauf. - Nach zehn weiteren Canvas im Chat ist der Block noch bedienbar. - `publish-plugins.sh`-Prüfung (Manifest-Validierung, Datenschutz-Scan) besteht; Veröffentlichung über `--dry-run` dann real.
alf commented 2026-10-24 15:38:01 +00:00
Author
Owner
Copy link

PR #249 gemergt: feat(comfyui-workflows): Starter für die Workflow-Verwaltung — autonomer Block ohne Modell-Lauf (0.3.0→3.3.0, iris/Iris#149) (#248)
#249

Commits:

  • feat(comfyui-workflows): Starter für die Workflow-Verwaltung — autonomer Block ohne Modell-Lauf (0.3.0→3.3.0, iris/Iris#149) (#248)

Stand — comfyui-workflows 3.3.0: Starter für die Workflow-Verwaltung (iris/Iris#149)

Befund

Der Block comfyui_workflow_manager existiert seit 3.0.0, aber ihn zu öffnen kostet einen
Modell-Lauf: Flow 8 im Skill — der Nutzer muss etwas sagen, Hermes zeigt den Canvas. Mit
launchers im Manifest erscheint ein Starter auf der Plugin-Karte und im Menu „Plugin-Block“
der Chat-Leiste; ein Klick führt die Aktion oeffnen aus und hängt den Block ohne Lauf an.

Geändert

  • actions/aktionen.py (neu): die deklarierte Aktion oeffnen — stdin-Kontrakt wie im
    Test-Plugin iris-starter-test, nur Standardbibliothek, gibt
    {"block": {"type": "comfyui_workflow_manager", "title": "ComfyUI-Workflows verwalten"}}
    zurück. Bewusst ein eigener Ordner: PluginActionsCore.collectFiles nimmt den ganzen
    Ordner jedes Skripts ins Skript-Paket — in scripts/ wäre die 79 KB workflow_registry.py
    unnötig in den Client-Cache gewandert.
  • plugin.json: actions_api: 1, autonomous_block_types: ["comfyui_workflow_manager"],
    runtime.python >=3.11, actions.oeffnen (timeout 30, beschreibung für Zustimmungs- und
    Installationsdialog), launchers (id workflow-manager, icon rectangle.3.group),
    changelog-Feld, iris_min_version 2.0.0 → 2.0.1 (Starter und autonome Typen gibt es
    erst ab dieser App), Version 3.3.0.
  • build-irisplugin.sh: Kopierschritt actions/.
  • Store/Doku: store/changelog.md Abschnitt 3.3.0, store-page.json (Feature „Verwaltung
    per Klick“, Glyph window) und neu generiertes store/hero.html, neuer Abschnitt
    „Die Verwaltungs-Oberfläche“ in docs/erste-schritte.md.
  • PLAN.md: Changelog-Zeile 2026-10-24, fehlende „Lessons Learned“-Überschrift ergänzt und
    zwei neue Lessons (Skript-Paket folgt dem Ordner; Starter und fetch-Routen sind verschiedene
    Ebenen).

Bewusst nicht geändert: web/canvas-block.html und die fetch-Registry-Routen
(/plugins/comfyui-workflows/registry/..., cfg_token) bleiben. Die Bibliothek liegt beim
verbundenen Server — irisCall-Aktionen liefen auf dem Client-Gerät gegen dessen eigene, leere
Bibliothek und würden den IrisClient-gegen-Linux-Server-Fall brechen. Kein irisSaveState: der
Bridge-Script wird in CanvasWorkflowManagerBlockView/PinnedWebView bisher nicht eingespielt
(nur in CanvasPluginWebBlockView).

Geprüft

  • Manifest gegen registry-tools/plugin_actions.py (dieselben Regeln wie PluginActionsCore):
    keine Fehler; script-Pfad sicher.
  • actions/aktionen.py lokal mit echtem stdin/stdout: gültiger Aufruf → {"ok": true, "result": {"block": …}}, kaputtes stdin → {"ok": false, "error": {"code": "eingabe", …}}, Exit 0.
  • Paket gebaut (build-irisplugin.sh): actions/aktionen.py im Paket, plugin.json mit allen
    neuen Feldern.
  • Datenschutz-Scan (privacy_scan.scan_all) über Manifest, Paket, store/ und docs/: keine
    Funde.
  • publish-plugins.sh comfyui-workflows --dry-run: „3.3.0: aktualisiert“.

Nicht geprüft

  • Nichts in der laufenden App. Kein Klick auf den Starter (Plugin-Karte, Chat-Leiste), kein
    Block in einem Chat, kein Zustimmungsdialog, kein „Block bleibt nach zehn weiteren Canvas
    bedienbar“. Erster echter Test folgt mit der Installation von 3.3.0 in Iris 2.0.1.
  • Kein automatischer Test für Manifest oder Skript (Plugin-Repos haben keine Testskript-Infra;
    die Prüfung läuft über die Publish-Pipeline).

Grenzen / offen

  • Gegen einen Linux-Server verbunden funktioniert der Starter nicht, solange
    iris-linux-server#91 GET /plugins/<id>/actions, GET /plugins/<id>/file und launchers in
    der plugins-Liste nicht nachzieht. Auf dem Mac (lokaler Server) läuft er ab Iris 2.0.1.
  • Die App-Seite für diesen Blocktyp ist der Sonderfall CanvasWorkflowManagerBlockView
    (fetch-Proxy), nicht der generische CanvasPluginWebBlockView; irisCall/irisSaveState
    stehen der Seite dort nicht zur Verfügung — für den Starter unerheblich, der Weg läuft über
    PluginActionsService.launch.
  • iris_min_version 2.0.1: ältere Iris-Versionen zeigen das Plugin im Marktplatz nicht mehr als
    installierbar.
PR #249 gemergt: feat(comfyui-workflows): Starter für die Workflow-Verwaltung — autonomer Block ohne Modell-Lauf (0.3.0→3.3.0, iris/Iris#149) (#248) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/249 Commits: - feat(comfyui-workflows): Starter für die Workflow-Verwaltung — autonomer Block ohne Modell-Lauf (0.3.0→3.3.0, iris/Iris#149) (#248) --- # Stand — comfyui-workflows 3.3.0: Starter für die Workflow-Verwaltung (iris/Iris#149) ## Befund Der Block `comfyui_workflow_manager` existiert seit 3.0.0, aber ihn zu öffnen kostet einen Modell-Lauf: Flow 8 im Skill — der Nutzer muss etwas sagen, Hermes zeigt den Canvas. Mit `launchers` im Manifest erscheint ein Starter auf der Plugin-Karte und im Menu „Plugin-Block“ der Chat-Leiste; ein Klick führt die Aktion `oeffnen` aus und hängt den Block ohne Lauf an. ## Geändert - **`actions/aktionen.py`** (neu): die deklarierte Aktion `oeffnen` — stdin-Kontrakt wie im Test-Plugin iris-starter-test, nur Standardbibliothek, gibt `{"block": {"type": "comfyui_workflow_manager", "title": "ComfyUI-Workflows verwalten"}}` zurück. Bewusst ein **eigener Ordner**: `PluginActionsCore.collectFiles` nimmt den ganzen Ordner jedes Skripts ins Skript-Paket — in `scripts/` wäre die 79 KB `workflow_registry.py` unnötig in den Client-Cache gewandert. - **`plugin.json`:** `actions_api: 1`, `autonomous_block_types: ["comfyui_workflow_manager"]`, `runtime.python >=3.11`, `actions.oeffnen` (timeout 30, `beschreibung` für Zustimmungs- und Installationsdialog), `launchers` (id `workflow-manager`, icon `rectangle.3.group`), `changelog`-Feld, `iris_min_version` 2.0.0 → **2.0.1** (Starter und autonome Typen gibt es erst ab dieser App), Version 3.3.0. - **`build-irisplugin.sh`:** Kopierschritt `actions/`. - **Store/Doku:** `store/changelog.md` Abschnitt 3.3.0, `store-page.json` (Feature „Verwaltung per Klick“, Glyph `window`) und neu generiertes `store/hero.html`, neuer Abschnitt „Die Verwaltungs-Oberfläche“ in `docs/erste-schritte.md`. - **`PLAN.md`:** Changelog-Zeile 2026-10-24, fehlende „Lessons Learned“-Überschrift ergänzt und zwei neue Lessons (Skript-Paket folgt dem Ordner; Starter und fetch-Routen sind verschiedene Ebenen). **Bewusst nicht geändert:** `web/canvas-block.html` und die fetch-Registry-Routen (`/plugins/comfyui-workflows/registry/...`, cfg_token) bleiben. Die Bibliothek liegt beim verbundenen Server — `irisCall`-Aktionen liefen auf dem Client-Gerät gegen dessen eigene, leere Bibliothek und würden den IrisClient-gegen-Linux-Server-Fall brechen. Kein `irisSaveState`: der Bridge-Script wird in `CanvasWorkflowManagerBlockView`/`PinnedWebView` bisher nicht eingespielt (nur in `CanvasPluginWebBlockView`). ## Geprüft - Manifest gegen `registry-tools/plugin_actions.py` (dieselben Regeln wie `PluginActionsCore`): keine Fehler; `script`-Pfad sicher. - `actions/aktionen.py` lokal mit echtem stdin/stdout: gültiger Aufruf → `{"ok": true, "result": {"block": …}}`, kaputtes stdin → `{"ok": false, "error": {"code": "eingabe", …}}`, Exit 0. - Paket gebaut (`build-irisplugin.sh`): `actions/aktionen.py` im Paket, `plugin.json` mit allen neuen Feldern. - Datenschutz-Scan (`privacy_scan.scan_all`) über Manifest, Paket, `store/` und `docs/`: keine Funde. - `publish-plugins.sh comfyui-workflows --dry-run`: „3.3.0: aktualisiert“. ## Nicht geprüft - **Nichts in der laufenden App.** Kein Klick auf den Starter (Plugin-Karte, Chat-Leiste), kein Block in einem Chat, kein Zustimmungsdialog, kein „Block bleibt nach zehn weiteren Canvas bedienbar“. Erster echter Test folgt mit der Installation von 3.3.0 in Iris 2.0.1. - Kein automatischer Test für Manifest oder Skript (Plugin-Repos haben keine Testskript-Infra; die Prüfung läuft über die Publish-Pipeline). ## Grenzen / offen - **Gegen einen Linux-Server verbunden funktioniert der Starter nicht**, solange iris-linux-server#91 `GET /plugins/<id>/actions`, `GET /plugins/<id>/file` und `launchers` in der `plugins`-Liste nicht nachzieht. Auf dem Mac (lokaler Server) läuft er ab Iris 2.0.1. - Die App-Seite für diesen Blocktyp ist der Sonderfall `CanvasWorkflowManagerBlockView` (fetch-Proxy), nicht der generische `CanvasPluginWebBlockView`; `irisCall`/`irisSaveState` stehen der Seite dort nicht zur Verfügung — für den Starter unerheblich, der Weg läuft über `PluginActionsService.launch`. - `iris_min_version` 2.0.1: ältere Iris-Versionen zeigen das Plugin im Marktplatz nicht mehr als installierbar.
alf commented 2026-10-25 12:25:43 +00:00
Author
Owner
Copy link

PR #257 gemergt: feat(comfyui-workflows): 3.4.0 — Plugin-Reiter mit gemeinsamer Workflow-Auswahl, select/selection + panel_api (#248)
#257

Commits:

  • feat(comfyui-workflows): 3.4.0 — Plugin-Reiter mit gemeinsamer Workflow-Auswahl, select/selection + panel_api (#248)

Befund: Der Plugin-Reiter (iris/Iris#169) hatte mit iris-solidcraft 0.2.0 seinen ersten Fall; comfyui-workflows war der zweite, vom Nutzer gewünschte. Die Verwaltungs-GUI war dafür unerwartet billig wiederverwendbar: web/canvas-block.html redet schon seit 3.0.0 ausschließlich über cfg_token + Registry-Routen — kein irisCall, kein postMessage. Der Reiter-Vertrag (panel_api) war erfüllt, bevor es ihn gab.

Geändert (3.3.0 → 3.4.0):

  • plugin.json: side_panel: "web/canvas-block.html" (dieselbe Datei wie web_view_path, kein zweiter Stand) + panel_api (config-status/status/select, Timeout 30 s).
  • scripts/workflow_registry.py: neu select --slug (leerer Slug hebt auf) und selection. Auswahl liegt in selection.json neben registry.json — Bedienzustand, kein Bibliotheksinhalt; überlebt register, und remove räumt sie mit, wenn der Entfernte der Ausgewählte war.
  • scripts/panel_api.py (neu): delegiert alles an workflow_registry.py, keine eigene Registry-Logik. status → chat_id (Quittung, kein Zugriffsnachweis: Bibliothek ist instanz-global) + summary (eine Zeile, Auswahl vorn) + detail (Bibliothek + Auswahl). select antwortet wie status, damit der Reiter ohne zweite Runde umzeichnet.
  • web/canvas-block.html: mit chat_id in der URL ist sie der Reiter — Klick setzt die gemeinsame Auswahl (bewusst kein eigener Knopf: zwei Wege für eine Absicht), Abzeichen + Hinweis; ohne chat_id exakt bisheriges Verhalten. @media (max-width: 560px) stapelt Liste über Detail (Reiter ist 320–900 pt). Nach remove Auswahl nachziehen.
  • SKILL.md: Abschnitt „Plugin-Reiter im Seitenpanel" + select/selection in der Werkzeugtabelle. build-irisplugin.sh kopiert panel_api.py. Anleitung und store/changelog.md für 3.4.0.

Warum keine Server-Änderung: POST /plugins/:id/api/:command ist auf Mac und Linux generisch vorhanden, beide lösen side_panel und workflow_registry.pys default_app_support() auf dieselbe Bibliothek.

Geprüft: 11 Unit-Tests grün — tests/test_selection_and_panel.py, die ersten Tests des Plugins überhaupt; beide Skripte als echte Subprocessen gegeneinander, Temp-Bibliothek aus seed/. Probe gegen die echte Bibliothek dieses Macs: summary „Kein Workflow ausgewählt · 9 Workflows in der Bibliothek", nach select „Ausgewählt: MiniMax Music 3 · 9 …". Dabei gefunden: der Mac-Runner (runPluginPanelAPIScript) setzt IRIS_APP_SUPPORT nicht (die Doku in InstalledPlugin.swift:316 verspricht es) — ohne Variable geprüft, der Fallback auf ~/Library/Application Support/Iris trägt, Linux-Container hat denselben Bind-Mount. Syntax-Check der Seite (node), Build OK.

Nicht geprüft: kein Klicktest in Iris (installiert ist 3.3.0, das neue Paket muss importiert werden); Reiter gegen den Linux-Server nicht gesehen; iOS nicht geprüft; der Marker [PLUGIN-PANEL: …] mit dieser Auswahl nie in einem echten Hermes-Lauf beobachtet. Nicht veröffentlicht — Veröffentlichen braucht dein Wort.

PR #257 gemergt: feat(comfyui-workflows): 3.4.0 — Plugin-Reiter mit gemeinsamer Workflow-Auswahl, select/selection + panel_api (#248) https://forgejo.lewerken.duckdns.org/iris/iris-plugins/pulls/257 Commits: - feat(comfyui-workflows): 3.4.0 — Plugin-Reiter mit gemeinsamer Workflow-Auswahl, select/selection + panel_api (#248) --- **Befund:** Der Plugin-Reiter (iris/Iris#169) hatte mit iris-solidcraft 0.2.0 seinen ersten Fall; comfyui-workflows war der zweite, vom Nutzer gewünschte. Die Verwaltungs-GUI war dafür unerwartet billig wiederverwendbar: `web/canvas-block.html` redet schon seit 3.0.0 ausschließlich über `cfg_token` + Registry-Routen — kein `irisCall`, kein `postMessage`. Der Reiter-Vertrag (`panel_api`) war erfüllt, bevor es ihn gab. **Geändert (3.3.0 → 3.4.0):** - `plugin.json`: `side_panel: "web/canvas-block.html"` (dieselbe Datei wie `web_view_path`, kein zweiter Stand) + `panel_api` (`config-status`/`status`/`select`, Timeout 30 s). - `scripts/workflow_registry.py`: neu `select --slug` (leerer Slug hebt auf) und `selection`. Auswahl liegt in `selection.json` **neben** `registry.json` — Bedienzustand, kein Bibliotheksinhalt; überlebt `register`, und `remove` räumt sie mit, wenn der Entfernte der Ausgewählte war. - `scripts/panel_api.py` (neu): delegiert alles an `workflow_registry.py`, keine eigene Registry-Logik. `status` → `chat_id` (Quittung, kein Zugriffsnachweis: Bibliothek ist instanz-global) + `summary` (eine Zeile, Auswahl vorn) + `detail` (Bibliothek + Auswahl). `select` antwortet wie `status`, damit der Reiter ohne zweite Runde umzeichnet. - `web/canvas-block.html`: mit `chat_id` in der URL ist sie der Reiter — Klick setzt die gemeinsame Auswahl (bewusst kein eigener Knopf: zwei Wege für eine Absicht), Abzeichen + Hinweis; ohne `chat_id` exakt bisheriges Verhalten. `@media (max-width: 560px)` stapelt Liste über Detail (Reiter ist 320–900 pt). Nach `remove` Auswahl nachziehen. - `SKILL.md`: Abschnitt „Plugin-Reiter im Seitenpanel" + `select`/`selection` in der Werkzeugtabelle. `build-irisplugin.sh` kopiert `panel_api.py`. Anleitung und `store/changelog.md` für 3.4.0. **Warum keine Server-Änderung:** `POST /plugins/:id/api/:command` ist auf Mac und Linux generisch vorhanden, beide lösen `side_panel` und `workflow_registry.py`s `default_app_support()` auf dieselbe Bibliothek. **Geprüft:** 11 Unit-Tests grün — `tests/test_selection_and_panel.py`, die ersten Tests des Plugins überhaupt; beide Skripte als echte Subprocessen gegeneinander, Temp-Bibliothek aus `seed/`. Probe gegen die echte Bibliothek dieses Macs: `summary` „Kein Workflow ausgewählt · 9 Workflows in der Bibliothek", nach `select` „Ausgewählt: MiniMax Music 3 · 9 …". Dabei gefunden: der Mac-Runner (`runPluginPanelAPIScript`) setzt `IRIS_APP_SUPPORT` **nicht** (die Doku in `InstalledPlugin.swift:316` verspricht es) — ohne Variable geprüft, der Fallback auf `~/Library/Application Support/Iris` trägt, Linux-Container hat denselben Bind-Mount. Syntax-Check der Seite (node), Build OK. **Nicht geprüft:** kein Klicktest in Iris (installiert ist 3.3.0, das neue Paket muss importiert werden); Reiter gegen den Linux-Server nicht gesehen; iOS nicht geprüft; der Marker `[PLUGIN-PANEL: …]` mit dieser Auswahl nie in einem echten Hermes-Lauf beobachtet. Nicht veröffentlicht — Veröffentlichen braucht dein Wort.
alf closed this issue 2026-10-27 10:40:30 +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#248
No description provided.