docs: IDEAS.md – Reihenfolge für App-Schublade, Widgets und offene Entscheidungen

Nur Notizen, keine Änderung am Verhalten. Hält fest, was aufeinander aufbaut
(Fundament → erstes Widget → Ausbau), welche zwei Entscheidungen offen sind
(Symbole, Token-Schlüssel) und was bewusst nicht geplant ist, damit iframes
und PWA-Weg nicht alle paar Monate neu diskutiert werden.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

IDEAS.md

@@ -0,0 +1,141 @@
+# Ideen und Reihenfolge
+
+Was noch kommen könnte, in der Reihenfolge, in der es aufeinander aufbaut.
+Nichts davon ist beschlossen — beschlossen ist, was im [README](README.md) steht.
+
+Grundsatz für alles hier: **Fundament zuerst, dann ein Widget, dann ausbauen.**
+Nicht zehn Fenster auf einmal planen, sondern eines bauen und sehen, ob man
+wirklich hinschaut.
+
+---
+
+## 1 · Fundament
+
+Ohne diese Stücke ist alles danach nicht möglich.
+
+### 1.1 App-Schublade in den Apps
+
+**Die Idee:** In Aether und InkNote ein Knopf, der eine Übersicht aller Apps
+aufklappt — mit Symbol. Die Liste kommt aus HoneyOS, nicht aus der App. Eine
+neue App trägt man einmal ein und sie taucht überall auf, ohne dass eine App
+angefasst wird.
+
+**Stand:** Die Hälfte steht schon. `honeybar.js` holt die Liste aus `/api/apps`,
+bringt seine eigene Sitzung mit und hat bereits ein Aufklappmenü. Was fehlt, ist
+die Darstellung als Raster mit Symbolen statt einer Textliste.
+
+**Der eigentliche Punkt: die Symbole.** Heute lebt das Pixelraster in `os.js`
+(`GLYPHS`), die Leiste kennt es nicht und zeigt nur Namen. Zwei Wege:
+
+- **Pixelglyphen teilen** — `GLYPHS` + `glyphSvg()` in eine eigene Datei, die
+  Desktop und Leiste beide laden. Kein Upload, kein Speicher, passt zum Look.
+  Nachteil: nur die eingebauten Symbole.
+- **Echte Bilder** — pro App eine Bildadresse oder ein Upload in HoneyOS.
+  Flexibler, aber: Speicher, Größenbegrenzungen, Auslieferung, und der
+  Retro-Look bekommt bunte Fremdkörper.
+
+→ **Empfehlung: Pixelglyphen teilen.** Eine gemeinsame Datei löst es. Bilder
+später nachrüsten, falls je eine App dabei ist, für die kein Symbol passt.
+
+### 1.2 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.3 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 die PWA und der Offline-Betrieb
+unangetastet bleiben.
+
+Erledigt das zugleich: der Token-Schlüssel in der App-Verwaltung wird überflüssig
+(siehe „Offene Entscheidungen").
+
+### 1.4 Widget-Rahmen im Desktop
+
+Ein Fenstertyp, der einen Inhalt holt, ihn anzeigt und sich benimmt, wenn es
+schiefgeht: lädt gerade, nichts da, nicht angemeldet, Fehler. Einmal richtig
+gebaut, kostet jedes weitere Widget danach fast nichts.
+
+Muss in **beiden Betriebsarten** funktionieren — im Desktop als Fenster, im
+Terminal als Kachel.
+
+---
+
+## 2 · Erste Widgets
+
+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
+
+→ Anfangen mit **letzte Dateien**. Wenn du danach merkst, dass du morgens
+wirklich draufschaust, lohnt der Rest. Wenn nicht, war es ein Abend.
+
+---
+
+## 3 · Ausbau
+
+- Welche Widgets wo liegen, **pro Nutzer im Server** merken — die Einstellungen
+  liegen ohnehin schon dort, das ist eine Erweiterung, kein Neubau
+- Widgets im Terminal-Modus
+- Suche über alle Apps hinweg (erst sinnvoll, wenn mehrere APIs angebunden sind)
+- Symbole frei auf dem Schreibtisch ablegen statt in einer Spalte
+- Fensterpositionen überleben den Moduswechsel
+
+---
+
+## Offene Entscheidungen
+
+### Token-Schlüssel behalten oder löschen?
+
+**Empfehlung: löschen.** Gründe:
+
+1. Er wirkt nur an einer von zwei Stellen — in der Leiste ja, auf dem Desktop
+   nie. Das ist schwer zu erklären und noch schwerer zu merken.
+2. Er bringt allein die Namensanzeige. Kein Funktionsunterschied.
+3. Sobald 1.3 gebaut ist, ist er ohnehin überflüssig.
+4. **Scharfe Kante:** Das Feld „Wer-bin-ich" darf auch eine vollständige fremde
+   Adresse sein. Steht dort etwas Fremdes *und* ein Token-Schlüssel, schickt die
+   Leiste den InkNote-Token dorthin. Das setzt voraus, dass jemand Angemeldetes
+   das selbst einträgt — bei einer Ein-Personen-Instanz also kein akuter
+   Notstand, aber eine Falle, die niemand braucht.
+
+Wird er doch behalten, gehört mindestens eingebaut: **mit Token-Schlüssel nur
+relative Pfade zulassen**, damit ein Ausweis nie an einen fremden Ursprung geht.
+Drei Zeilen.
+
+### Ideen hier oder als Gitea-Issues?
+
+Vorerst hier. Issues erst, wenn etwas konkret als Nächstes drankommt und der
+Fortschritt verfolgt werden soll — dann eines pro Punkt, mit Verweis hierher.
+
+---
+
+## Bewusst nicht geplant
+
+Damit es nicht alle paar Monate neu diskutiert wird:
+
+- **Apps in iframes einbetten.** Aether (`X-Frame-Options: DENY`) und InkNote
+  (`helmet()`) verbieten es beide von sich aus, und das aus gutem Grund. Es
+  würde Clickjacking-Schutz, PWA-Installierbarkeit und InkNotes Offline-Betrieb
+  kosten. Widgets zeigen **Daten**, die Apps bleiben in ihrem eigenen Tab.
+- **Der Weg aufs Handy bleibt ein normaler Link.** Android öffnet die
+  installierte PWA, wenn die Adresse in ihren Bereich fällt — das funktioniert
+  heute und darf nicht durch JavaScript-Navigation oder Rahmen kaputtgemacht
+  werden.
+- **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
+  Handvoll eigene Konten gewollt; wäre es je mehr, müsste das neu gedacht werden.