diff --git a/IDEAS.md b/IDEAS.md
index 626955f..ced472e 100644
--- a/IDEAS.md
+++ b/IDEAS.md
@@ -86,30 +86,9 @@ später eine CSS-Zeile; ohne sie anzufangen kostet die Zeit, in der man rät.
Der Untertitel bekommt damit endlich einen Ort: Er stand bisher nur auf den
Kacheln und beantwortet genau die Frage, die ein generisches Symbol offenlässt.
-**Ebenfalls offen: eigene Logos hochladen** (beschlossen als Planung,
-25.08.2026). Je App ein Bild in HoneyOS, die Pixelglyphe als Rückfall, wenn
-keins da ist. Das Logo gehört ausdrücklich auch in die HoneyBar — dort ist die
-Unterscheidung am nötigsten, weil die Knöpfe klein sind und nebeneinanderstehen.
-Der Weg dorthin ist durch die geteilte Quelle jetzt kurz: Beide Seiten holen
-ihre Symbole schon aus derselben Antwort, es müsste nur ein Bild an die Stelle
-des Rasters treten können.
-
-Was daran zu bauen ist, in dieser Reihenfolge:
-
-1. **Hochladen und ablegen** — HoneyOS speichert heute nur eine JSON-Datei.
- Bilder heißt: ein Ordner unter `/data`, eine Größenbegrenzung, erlaubte
- Typen (PNG, SVG, WebP), und SVG ist heikel — es kann Skripte enthalten und
- darf deshalb nicht einfach durchgereicht werden.
-2. **Ausliefern** — unter einer Adresse je App, mit einem Versionsanteil, damit
- ein Austausch nicht im Cache hängen bleibt (Aether macht das beim Logo
- schon so).
-3. **In der HoneyBar anzeigen** — über die Site-Grenze hinweg ein `
` von
- HoneyOS. Das geht ohne Sitzung, Bilder unterliegen der CORS-Regel nicht.
-
-**Vorher zu klären:** Sollen Bilder in den Retro-Look eingepasst werden
-(auf wenige Farben reduziert, hart gerastert) oder bunt bleiben? Ein
-Original-Logo mit Farbverlauf neben Pixelglyphen sieht schnell nach Fremdkörper
-aus. Ein Filter in der HoneyBar wäre billig zu haben und ließe sich abschalten.
+**Was aus 1.3 offen bleibt, steht jetzt weiter unten:** eigene Logos zum
+Hochladen (siehe „Eigene App-Logos" in Teil 2). Sie hängen an derselben Ablage
+wie das Bild-Widget und gehören deshalb dorthin, nicht mehr ins Fundament.
### 1.3b Reihenfolge der Apps
@@ -306,6 +285,40 @@ Zu klären, wenn es soweit ist:
- Passt zum Aufnehmen eigener App-Logos (1.3): dieselbe Ablage, dasselbe
Ausliefern. Zusammen bauen spart die Hälfte.
+### Eigene App-Logos — verschoben aus 1.3 (29.08.2026)
+
+**Beschlossen als Planung (25.08.2026), aber nicht als Nächstes.** Je App ein
+Bild in HoneyOS hinterlegen, statt nur aus den eingebauten Glyphen zu wählen —
+die Pixelglyphe bleibt der Rückfall, wenn keins da ist.
+
+Das Logo gehört ausdrücklich **auch in die HoneyBar**, nicht nur auf den
+Schreibtisch: Dort ist die Unterscheidung am nötigsten, weil die Knöpfe klein
+sind und nebeneinanderstehen. Die Voraussetzung dafür — eine geteilte
+Symbolquelle für beide Leisten — steht seit dem 29.08.2026 (1.3), es müsste nur
+ein Bild an die Stelle des Rasters treten können.
+
+**Warum es warten kann:** Mit acht Glyphen und vier Apps ist noch keine
+Verwechslung in Sicht. Die Frage stellt sich, wenn zwei Dienste dieselbe Wolke
+tragen; bis dahin erledigt der Untertitel in der Schublade die Unterscheidung.
+
+**Warum es zusammen mit dem Bild-Widget zu bauen ist:** dieselbe Ablage,
+dasselbe Ausliefern, dieselben Fallen — zusammen kostet es die Hälfte.
+
+1. **Hochladen und ablegen** — HoneyOS speichert heute nur eine JSON-Datei.
+ Bilder heißt: ein Ordner unter `/data`, eine Größenbegrenzung, erlaubte
+ Typen (PNG, SVG, WebP), und SVG ist heikel — es kann Skripte enthalten und
+ darf deshalb nicht einfach durchgereicht werden.
+2. **Ausliefern** — unter einer Adresse je App, mit einem Versionsanteil, damit
+ ein Austausch nicht im Cache hängen bleibt (Aether macht das beim Logo
+ schon so).
+3. **In der HoneyBar anzeigen** — über die Site-Grenze hinweg ein `
` von
+ HoneyOS. Das geht ohne Sitzung, Bilder unterliegen der CORS-Regel nicht.
+
+**Vorher zu klären:** Sollen Bilder in den Retro-Look eingepasst werden (auf
+wenige Farben reduziert, hart gerastert) oder bunt bleiben? Ein Original-Logo
+mit Farbverlauf neben Pixelglyphen sieht schnell nach Fremdkörper aus. Ein
+Filter in der HoneyBar wäre billig zu haben und ließe sich abschalten.
+
### Widgets verschieben, Reihenfolge im Server — Marcs Idee (29.08.2026)
Widgets per Ziehen umsortieren, die Reihenfolge liegt beim Nutzer auf dem