Kategorien sind Zeilen in der Liste, kein Feld am Formular

Marcs Vorschlag, und er ist der bessere: "+ kategorie" setzt eine
Ueberschriftenzeile, und was darunter steht, gehoert dazu, bis die naechste
kommt. Die Ueberschrift hat dieselben Pfeile wie eine App, laesst sich
umbenennen und mit x aufloesen.

Damit faellt die Sonderregel von gestern weg -- "am Rand der Gruppe
kategorisiert der Pfeil um, statt zu tauschen". Sie war die Beschreibung
eines Modells; jetzt ist es das Modell: Schiebt man eine App ueber eine
Ueberschrift, ist sie in der anderen Gruppe, und schiebt man eine
Ueberschrift, wandert die Grenze. Nichts davon braucht Code.

Vor allem loest es den echten Mangel der ersten Fassung: Eine Kategorie
umbenennen war ein Feld je App, jetzt ist es eine Zeile.

Gespeichert wird weiter als Feld an der App. Waere die Ueberschrift ein
Eintrag in der App-Liste, enthielte diese Zeilen ohne ID und ohne Adresse,
und jeder Leser muesste das wissen -- Kacheln, Schublade, Pruefung auf
Erreichbarkeit und vor allem die HoneyBar in fremden Apps. Der Preis: Eine
Ueberschrift ohne Apps darunter ueberlebt das Speichern nicht. Eine
Kategorie besteht durch ihre Apps.

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

IDEAS.md

@@ -392,18 +392,27 @@ unter 64 px unbrauchbar, taugt aber für ein großes Startbild.
 
 ### Kategorien für Apps — ✅ gebaut (12.09.2026)
 
-Überschriften über den Apps, damit aus einer Liste eine Ordnung wird. Gebaut als
-**ein Feld an der App**, nicht als zweites Datenmodell: Eine Kategorie besteht,
-solange eine App sie trägt — kein Anlegen, kein Löschen, keine zweite
-Reihenfolge neben der bestehenden.
+Überschriften über den Apps, damit aus einer Liste eine Ordnung wird.
 
-Die Reihenfolge der Gruppen ist die ihres ersten Auftretens, also ordnen
-dieselben Pfeile beides. Am Rand einer Gruppe kategorisiert der Pfeil um, statt
-zu tauschen — sonst bräuchte es einen zweiten Knopf, und eine App könnte
-zwischen zwei Gruppen liegen bleiben.
+**In zwei Anläufen gebaut, und der zweite kam von Marc.** Zuerst war die Kategorie
+ein Feld im App-Formular, und die Pfeile bekamen eine Sonderregel: Am Rand einer
+Gruppe kategorisieren statt tauschen. Das funktionierte, war aber die Beschreibung
+eines Modells und nicht das Modell selbst. Seine Frage — warum nicht einfach eine
+Überschriftenzeile in der Liste, und was darunter steht, gehört dazu? — ist die
+bessere Bedienung: Man sieht, was man sortiert, das Umhängen ergibt sich von
+selbst, und **Umbenennen ist eine Zeile statt eines Feldes je App**. Genau das war
+der Mangel der ersten Fassung.
 
-Eingesammelt wird **im Server**, beim Schreiben wie beim Lesen. Das war nicht der
-erste Entwurf: Zuerst sortierte die Oberfläche und die HoneyBar setzte ihre
+**Gespeichert wird trotzdem als Feld an der App.** Die Überschrift gibt es nur im
+Editor. Wäre sie ein Eintrag in der App-Liste, enthielte diese Zeilen ohne ID und
+ohne Adresse, und jeder Leser müsste das wissen — Kacheln, Schublade,
+Erreichbarkeitsprüfung, und vor allem die HoneyBar in fremden Apps, die gerade
+erst auf das Nötigste getrimmt wurde. Der Preis: Eine Überschrift ohne Apps
+darunter überlebt das Speichern nicht. Das ist vertretbar — eine Kategorie besteht
+durch ihre Apps.
+
+Eingesammelt wird **im Server**, beim Schreiben wie beim Lesen. Auch das war nicht
+der erste Entwurf: Zuerst sortierte die Oberfläche und die HoneyBar setzte ihre
 Überschriften beim Durchlaufen — prompt stand eine App ohne Kategorie in der
 HoneyBar unter der letzten Überschrift und auf dem Schreibtisch ganz oben. Bei
 zwei Lesern derselben Liste gehört die Reihenfolge dorthin, wo die Liste liegt.
@@ -412,6 +421,10 @@ Offen gelassen: Schreibtischsymbole bleiben flach (Ordner wären ein eigenes
 Thema), und der App-Streifen der Leiste bekommt keine Überschriften — dort ist
 kein Platz.
 
+**Falls eine leere Kategorie doch bleiben soll**, ist das das Argument für eine
+echte Kategorienliste im Server — dann aber als eigenes Feld neben `apps`, nicht
+als Eintrag in ihr.
+
 ### Eigene App-Logos — verschoben aus 1.3 (29.08.2026)
 
 **Beschlossen als Planung (25.08.2026), aber nicht als Nächstes.** Je App ein