Listen zu Projekten gruppieren (mehrere Unterlisten unter einem gemeinsamen Projekt) #150
Labels
No labels
priority/could
priority/must
priority/should
priority/wont
status/blocked
status/claimed
status/done-migrated
type/bug
type/feature
type/infra
type/tech-debt
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
robert/todo#150
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Story: Listen zu Projekten gruppieren (mehrere Unterlisten unter einem gemeinsamen Projekt)
As a Nutzer, der ein größeres Vorhaben mit mehreren Listen organisiert,
I want to mehrere bestehende Listen (z. B. Einkaufsliste + Todo-Liste "Orga-Punkte") zu einem
gemeinsamen Projekt gruppieren,
so that ich z. B. für "Geburtstagsparty" alle zugehörigen Listen gebündelt sehe statt verstreut
in der Gesamtübersicht.
Background
Nicht zu verwechseln mit
#92("Projekt-/Meilenstein-Liste") — dort ist "Projekt" ein einzelnerListentyp mit Fortschrittsbalken über die eigenen Todos. Hier geht es um eine übergeordnete
Gruppierung/Ordner-Struktur, die mehrere unterschiedliche, bereits existierende Listen(-typen)
zusammenfasst.
Acceptance criteria:
dieser Gruppe zuordnen.
Abschnitt) statt einer flachen Liste.
Mehrfachzuordnung).
Out of scope for this story:
als Folge-Story betrachtet werden).
Open questions: (escalate to human if unanswered)
gemeinsam sichtbar?
Geschlossen als durch #170 abgedeckt: Nach Rücksprache mit dem Menschen (2026-09-07) wird aktuell keine geteilte/kollaborative Projekt-Gruppierung benötigt, bei der alle Mitglieder einer Liste dieselbe Zuordnung sehen. Eine rein persönliche Gruppierung per frei benennbaren Überschriften innerhalb der eigenen Listenreihenfolge (#170, direkte Folge-Story zu #147/#149) deckt den tatsächlichen Bedarf vollständig ab, ohne die zusätzliche Komplexität einer echten Projekt-Entität (Zuordnungs-Beziehung, Sharing-Semantik, projektweite Features).
Falls sich das später ändert — z. B. ein echter Wunsch nach einer für alle Mitglieder geteilten Projekt-Struktur mit eigenen Features wie einem gemeinsamen Fortschrittsbalken über mehrere Listen — sollte dafür ein neues Issue mit aktualisiertem Kontext angelegt werden, statt dieses hier wieder zu öffnen.