Schublade: Symbol, Name, Untertitel

Der Pfeil rechts klappt in beiden Leisten ein Raster auf statt einer
Liste. Symbol gross, Name, Untertitel als dritte Zeile — der stand
bisher nur auf den Kacheln.

Entschieden gegen Symbol allein: Acht geteilte Glyphen identifizieren
nicht, zwei Apps koennen dieselbe Wolke tragen. Und die Schublade macht
man auf, weil man sucht — der Streifen ist der Ort fuers Wiedererkennen,
dort sind die Symbole abschaltbar.

Dazu 1.4 (CORS in Aether) und 1.5 (Cookie-Sitzung fuer InkNote) aus den
Ideen gestrichen: Widgets, die Daten aus den eigenen Apps holen, sind
nicht mehr gewollt. Der Rest ist neu durchnummeriert.

IDEAS.md

@@ -59,7 +59,7 @@ hält — dieselbe Liste, die heute schon die CORS-Freigabe steuert. Das ist ein
 Sicherheitsentscheidung und keine Kleinigkeit; erst bauen, wenn der Umweg über
 den Schreibtisch wirklich nervt.
 
-### 1.3 App-Schublade mit Symbolen — ✅ halb gebaut (29.08.2026)
+### 1.3 App-Schublade mit Symbolen — ✅ gebaut (29.08.2026)
 
 **Gebaut: die geteilte Symbolquelle.** Die Raster liegen in `web/glyphs.json`,
 der Schreibtisch lädt sie, die HoneyBar bekommt sie mit der App-Liste mit
@@ -71,9 +71,20 @@ aus, für beide Leisten zugleich. In den Aufklappmenüs und auf den Kacheln
 stehen sie immer — dort ist Platz, und dort sucht man eine App, statt sie im
 Vorbeigehen wiederzuerkennen.
 
-**Offen bleibt die Schublade selbst:** ein Raster aus Symbolen statt einer
-Liste, wenn es viele Apps werden. Heute reicht der Streifen samt Menü; das ist
-erst ab sechs, sieben Apps eine echte Frage.
+**Ebenfalls gebaut: die Schublade.** Der Pfeil rechts klappt in beiden Leisten
+ein Raster auf — Symbol groß, Name, Untertitel als dritte Zeile. Drei Spalten,
+am Handy dieselben drei.
+
+Entschieden (29.08.2026): **Symbol und Name, nie nur Symbol.** Der Grund ist
+nicht Geschmack, sondern der geteilte Satz von acht generischen Glyphen — zwei
+Apps können dieselbe Wolke tragen, und bei Homelab-Diensten ist das der
+Normalfall. Ein Symbol identifiziert erst, wenn es einzigartig ist. Dazu: Den
+Streifen sieht man im Vorbeigehen, die Schublade macht man auf, *weil man
+sucht* — Suchen heißt Lesen, und Platz ist dort genug. Namen wegzunehmen ist
+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
@@ -121,28 +132,7 @@ HoneyBar. Zählen, wie oft etwas benutzt wird, heißt Nutzungsdaten speichern
 dafür ist der Nutzen hier zu klein. **Zu entscheiden, sobald die vierte App
 dazukommt**, nicht vorher.
 
-### 1.4 CORS in Aether
-
-Damit der Desktop Aether überhaupt etwas fragen darf. Aethers Sitzung ist ein
-Cookie, und weil alles unter derselben Domain liegt, schickt der Browser es
-schon heute mit — es fehlt allein die Freigabe im Go-Backend
-(`Access-Control-Allow-Origin` für `os.…` plus `Allow-Credentials`).
-
-Kleiner Eingriff, aber **die Voraussetzung für jedes Aether-Widget** und
-nebenbei auch für die Anmeldeanzeige auf der Kachel.
-
-### 1.5 InkNote: Sitzung zusätzlich als Cookie
-
-InkNote weist sich mit einem Bearer-Token aus, der im localStorage liegt. Der
-ist **pro Domain** — von `os.…` aus grundsätzlich unerreichbar, und daran ändert
-keine Konfiguration etwas.
-
-Solange das so bleibt, kann HoneyOS **keine InkNote-Daten anzeigen**. Der Weg
-wäre, dass InkNote seine Sitzung zusätzlich als `HttpOnly`-Cookie setzt; der
-Token-Weg kann daneben bleiben, damit PWA und Offline-Betrieb unangetastet sind.
-
-
-### 1.5b HoneyOS selbst als PWA
+### 1.4 HoneyOS selbst als PWA
 
 Heute ist HoneyOS eine Website: Es hat `theme-color`, aber kein Manifest, kein
 Symbol und keinen Service Worker — installierbar ist es damit nicht. Am Handy
@@ -179,7 +169,7 @@ Cache nur als Rückfall.
 Ursprungswechsel macht aus einer installierten PWA eine fremde App — wer
 vorher installiert, installiert zweimal.
 
-### 1.6 Widget-Rahmen
+### 1.5 Widget-Rahmen
 
 Ein Fenstertyp, der einen Inhalt holt, ihn anzeigt und sich benimmt, wenn es
 schiefgeht: lädt gerade, nichts da, nicht angemeldet, Fehler. Einmal richtig
@@ -192,9 +182,9 @@ Terminal als Kachel.
 
 Eines bauen, benutzen, dann entscheiden.
 
-- **Letzte Dateien** (Aether) — die naheliegendste; braucht nur 1.2
-- **Speicherplatz** (Aether) — eine Zahl, ein Balken, billig zu bauen
-- **Letzte Notizen** (InkNote) — braucht 1.3, kommt also später
+Widgets, die Daten aus den eigenen Apps holen, sind gestrichen (siehe „Bewusst
+nicht geplant"). Was bleibt, ist alles, was für sich allein steht: Wetter
+(gebaut), ein Bild, später vielleicht Uhr, Notizzettel, Systemzustand.
 
 ### Wetter in der HoneyBar, neben der Uhr — ✅ gebaut (25.08.2026)
 
@@ -338,7 +328,7 @@ schon gebaut) oder am Handy Pfeiltasten statt Ziehen anbieten. Nicht vergessen:
 Ohne das ist die Funktion am Handy schlicht nicht da.
 
 Voraussetzung ist ein Widget-Verzeichnis — heute stehen Benutzer und Wetter
-fest im HTML. Sinnvoll zusammen mit dem Widget-Rahmen (1.6) zu bauen, nicht
+fest im HTML. Sinnvoll zusammen mit dem Widget-Rahmen (1.5) zu bauen, nicht
 davor.
 
 ### Widgets in der HoneyBar selbst
@@ -348,17 +338,12 @@ ist aber die Seite, die man am seltensten offen hat — die HoneyBar dagegen ist
 überall. Naheliegend also: ein Knopf in der HoneyBar klappt dasselbe Widget als
 kleines Feld auf, ohne die App zu verlassen.
 
-Technisch ist das dieselbe Sache wie 1.6, nur ein zweites Zuhause für denselben
+Technisch ist das dieselbe Sache wie 1.5, nur ein zweites Zuhause für denselben
 Inhalt: Der Rahmen muss dann drei Formen können — Fenster, Kachel, Aufklappfeld.
-Das ist beim **Bauen** von 1.6 zu bedenken, hinterher wird es teuer.
+Das ist beim **Bauen** von 1.5 zu bedenken, hinterher wird es teuer.
 
-**Eine Einschränkung vorweg:** Die HoneyBar läuft in einer fremden App. Ein
-Aether-Widget in der HoneyBar **von InkNote aus** braucht deshalb dasselbe, was
-1.4 für den Schreibtisch regelt, nur für einen weiteren Ursprung. In der App
-selbst (Aether-Widget in Aethers eigener HoneyBar) ist es geschenkt.
-
-→ Anfangen mit **letzte Dateien**. Wenn du danach merkst, dass du morgens
-wirklich draufschaust, lohnt der Rest. Wenn nicht, war es ein Abend.
+Für Widgets, die nur sich selbst brauchen (Wetter, Bild, Uhr), ist das
+geschenkt — sie fragen HoneyOS, nicht die App.
 
 ---
 
@@ -508,6 +493,11 @@ Damit es nicht alle paar Monate neu diskutiert wird:
   installierte PWA, wenn die Adresse in ihren Bereich fällt — das funktioniert
   heute und darf nicht durch JavaScript-Navigation oder Rahmen kaputtgemacht
   werden.
+- **Keine Widgets, die Daten aus Aether oder InkNote holen** (gestrichen
+  29.08.2026). Dafür standen einmal zwei Punkte im Fundament: CORS in Aether
+  und eine Cookie-Sitzung für InkNote. Beides ist nicht mehr gewollt — der Weg
+  über den HoneyBar-Proxy zeigt HoneyOS in den Apps, statt die Apps in HoneyOS
+  nachzubauen.
 - **HoneyOS speichert keine Inhalte.** Keine Dateien, keine Notizen, keine
   Kopien. Es zeigt, was die Apps hergeben, und hört da auf.
 - **Keine Rechteverwaltung.** Die App-Liste gilt für alle Angemeldeten. Für eine