#91 — Neuer Listentyp "Priorisierte Liste" #90

New issue

Closed

opened 2026-08-18 13:13:50 +02:00 by lena · 1 comment

lena commented

2026-08-18 13:13:50 +02:00

(Migrated from git.butzei.de)

Story: Neuer Listentyp "Priorisierte Liste"

As a list member,
I want to meine To-Dos nach Dringlichkeit und Wichtigkeit auf einer Skala von 1–100 einordnen und in einer
2D-Matrix sehen können,
so that ich Aufgaben mit hoher Wichtigkeit, aber geringer gefühlter Dringlichkeit (die ich sonst liegen
lasse), tatsächlich umsetze.

Depends on: #89 (Listentyp-Vereinheitlichung — dieser Typ ist "Priorisierte Liste" darin).

Acceptance criteria:

Neuer Listentyp "Priorisiert" wählbar bei Listenerstellung (siehe #89).
Jedes Todo in einer Liste dieses Typs hat zwei zusätzliche numerische Felder: Dringend (1–100) und
Wichtig (1–100) — unabhängig von der bestehenden Priority-Einstufung (Low/Normal/High), die bei
diesem Typ nicht verwendet/angezeigt wird.
Sortierung nach der Formel Dringend + Faktor × Wichtig, absteigend, Faktor als Listeneinstellung pro
Liste konfigurierbar, Default 1,1.
Zwei umschaltbare Ansichten, beide nach Label filterbar:
- 2D-Karte: Achsen Dringend (x) / Wichtig (y), alle Todos als Punkte/Karten positioniert. Ein bestehender
  Punkt kann direkt auf der Karte gezogen (Drag) werden, um Dringend/Wichtig nachträglich zu verändern —
  nicht nur beim Anlegen über das Modal.
- Klassische Liste: ausschließlich nach obiger Formel sortiert, keine Kategorie-Gruppierung (bewusste
  Entscheidung — die Formel-Sortierung ist der Zweck dieser Ansicht, eine Kategorie-Gruppierung würde sie
  durchbrechen).
Neues Todo anlegen öffnet ein eigenes Modal (nicht die kleine Eingabezeile unten, anders als bei Standard-
und Einkaufslisten) mit:
- Titel-Eingabefeld.
- Numerische Felder Dringend/Wichtig, Default je 50.
- Mini-2D-Karte zum Anklicken: ein Klick setzt die Position und aktualisiert die beiden Zahlenfelder;
  umgekehrt aktualisieren Änderungen an den Zahlenfeldern die Position auf der Mini-Karte.
- Label-Auswahl inklusive Möglichkeit, direkt ein neues Label anzulegen.
Volle bestehende Todo-Feature-Palette bleibt erhalten: Fälligkeitsdatum, Zuweisung, Subtasks/Checkliste,
Kommentare, Wiederholung, Kategorien.

Out of scope for this story:

Änderungen an der bestehenden Priority-Einstufung für andere Listentypen — bleibt unangetastet.

# Story: Neuer Listentyp "Priorisierte Liste" **As a** list member, **I want to** meine To-Dos nach Dringlichkeit und Wichtigkeit auf einer Skala von 1–100 einordnen und in einer 2D-Matrix sehen können, **so that** ich Aufgaben mit hoher Wichtigkeit, aber geringer gefühlter Dringlichkeit (die ich sonst liegen lasse), tatsächlich umsetze. **Depends on:** `#89` (Listentyp-Vereinheitlichung — dieser Typ ist "Priorisierte Liste" darin). **Acceptance criteria:** - [ ] Neuer Listentyp "Priorisiert" wählbar bei Listenerstellung (siehe `#89`). - [ ] Jedes Todo in einer Liste dieses Typs hat zwei zusätzliche numerische Felder: **Dringend** (1–100) und **Wichtig** (1–100) — unabhängig von der bestehenden `Priority`-Einstufung (Low/Normal/High), die bei diesem Typ nicht verwendet/angezeigt wird. - [ ] Sortierung nach der Formel `Dringend + Faktor × Wichtig`, absteigend, Faktor als Listeneinstellung pro Liste konfigurierbar, Default `1,1`. - [ ] Zwei umschaltbare Ansichten, beide nach Label filterbar: - **2D-Karte:** Achsen Dringend (x) / Wichtig (y), alle Todos als Punkte/Karten positioniert. Ein bestehender Punkt kann direkt auf der Karte gezogen (Drag) werden, um Dringend/Wichtig nachträglich zu verändern — nicht nur beim Anlegen über das Modal. - **Klassische Liste:** ausschließlich nach obiger Formel sortiert, **keine** Kategorie-Gruppierung (bewusste Entscheidung — die Formel-Sortierung ist der Zweck dieser Ansicht, eine Kategorie-Gruppierung würde sie durchbrechen). - [ ] Neues Todo anlegen öffnet ein eigenes Modal (nicht die kleine Eingabezeile unten, anders als bei Standard- und Einkaufslisten) mit: - Titel-Eingabefeld. - Numerische Felder Dringend/Wichtig, Default je 50. - Mini-2D-Karte zum Anklicken: ein Klick setzt die Position und aktualisiert die beiden Zahlenfelder; umgekehrt aktualisieren Änderungen an den Zahlenfeldern die Position auf der Mini-Karte. - Label-Auswahl inklusive Möglichkeit, direkt ein neues Label anzulegen. - [ ] Volle bestehende Todo-Feature-Palette bleibt erhalten: Fälligkeitsdatum, Zuweisung, Subtasks/Checkliste, Kommentare, Wiederholung, Kategorien. **Out of scope for this story:** - Änderungen an der bestehenden `Priority`-Einstufung für andere Listentypen — bleibt unangetastet.

lena commented

2026-08-18 13:13:51 +02:00

(Migrated from git.butzei.de)

design (91_priority_matrix_list_type_design.md)

Design: `#91` — Priorisierte Liste (Dringend/Wichtig-Matrix)

Kernentscheidung: Variante der Todo-Liste, nicht Sibling-Entity

TodoListEntity bekommt eine neue Type-Spalte (Standard | Priority), TodoEntity bekommt zwei
nullable Zusatzfelder (Urgency, Importance) und TodoListEntity ein nullable
PriorityMatrixFactor — kein neuer Entity-Baum.

Begründung: #91 verlangt explizit "volle bestehende Todo-Feature-Palette bleibt erhalten:
Fälligkeitsdatum, Zuweisung, Subtasks/Checkliste, Kommentare, Wiederholung, Kategorien". Eine
Sibling-Entity nach dem Vorbild von #93 (Masterpackliste) müsste jedes dieser Features neu bauen —
das widerspricht der AC direkt. Priority ist inhaltlich eine Variante der Todo-Liste
(dieselben Todos, andere Anordnung/Zusatzachsen), nicht eine strukturell andere Domain wie
Shopping/Pantry/Masterpack.

Damit weicht diese Story bewusst von #89's "kein ListType-Enum/-Spalte"-Ruling ab. #89 selbst
hat diese Öffnung offengelassen: "Für #91–94 ist das eine eigene künftige Architect-Entscheidung
— spekulative Enum-Werte für noch nicht gebaute Typen würden jetzt nur Risiko ohne Nutzen
hinzufügen (YAGNI)." Der Enum-Wert wird hier für einen konkret gebauten Typ eingeführt, nicht
spekulativ; der YAGNI-Grund entfällt damit.

Schema-Änderungen

`TodoListEntity`

Type — neuer TodoListType-Enum (Standard = 0, Priority = 1), NOT NULL, default Standard.
PriorityMatrixFactor — nullable double, nur bei Type = Priority gesetzt, Default 1.1.
Range-Validation im VO (0.0 < factor ≤ 10.0). Nullable statt "nur ignoriert" damit der Zustand
"keine Priorisierungs-Liste" strukturell unmissverständlich bleibt und ein späterer Type-Wechsel
(aktuell nicht vorgesehen — Type ist bei Erstellung fixiert) nicht magisch einen Faktor mitführt.

`TodoEntity`

Urgency — nullable TodoUrgency (1–100), gesetzt nur bei Todos auf einer Priority-Liste.
Importance — nullable TodoImportance (1–100), gesetzt nur bei Todos auf einer Priority-Liste.

Beide nullable, weil dieselbe TodoEntity-Tabelle Todos beider List-Typen enthält. Bei
Standard-Listen bleiben die Felder NULL und werden vom Frontend nicht abgefragt/angezeigt.

Die bestehende Priority-Spalte (Low/Normal/High) bleibt strukturell erhalten und wird für
Priority-Listen vom Frontend schlicht nicht mehr angeboten — AC-konform ("bei diesem Typ nicht
verwendet/angezeigt").

Neue Vogen-VOs

TodoListType (Enum, Standard | Priority).
TodoUrgency (int, 1–100).
TodoImportance (int, 1–100).
PriorityMatrixFactor (double, 0.0 < x ≤ 10.0).

Bereich 1–100 statt 0–100 spiegelt die AC-Formulierung wörtlich ("auf einer Skala von 1–100").

Neue/erweiterte Commands & Queries

CreateTodoListCommand — bekommt optionalen Type-Parameter (default Standard) und
optionalen PriorityMatrixFactor (nur bei Type = Priority gesetzt). Zwei bestehende
Handler-Aufrufe (CreateTodoListCommandHandler, dessen Tests, Frontend-CreateListDialog) auf
die erweiterte Signatur ziehen.
CreateTodoCommand — bekommt optionale Urgency/Importance-Parameter, die nur gesetzt
werden dürfen wenn die Ziel-Liste Type = Priority hat (Handler validiert). Bei Standard-Listen
MÜSSEN sie null sein; bei Priority-Listen SOLLEN sie gesetzt sein (nicht zwingend im Handler
erzwungen — Frontend schickt sie immer; sonst greift der Default 50/50 der V1-Semantik).
Neu: SetTodoUrgencyImportanceCommand (id + urgency + importance). Muss geprüft werden: die
Ziel-Liste ist vom Typ Priority; sonst 400.
Neu: SetPriorityMatrixFactorCommand (id + factor). Owner-only (spiegelt
SetTodoListAppearanceCommand's Owner-Regel — pro-Liste-Konfig).

Migration

Ein Migration-File mit drei DDL-Schritten:

ALTER TABLE "TodoListEntity" ADD COLUMN "Type" TEXT NOT NULL DEFAULT 'Standard'.
ALTER TABLE "TodoListEntity" ADD COLUMN "PriorityMatrixFactor" DOUBLE PRECISION NULL.
ALTER TABLE "TodoEntity" ADD COLUMN "Urgency" INTEGER NULL,
ALTER TABLE "TodoEntity" ADD COLUMN "Importance" INTEGER NULL.

Kein Backfill nötig — Bestandslisten sind alle Type = Standard, Todos haben NULL
Urgency/Importance.

Frontend — V1-Scope

Menschlicher PO hat 2026-08-09 in der laufenden Session entschieden, die volle 2D-Scatter-Ansicht
mit Drag-to-Reposition in einen Follow-up zu ziehen. V1 liefert stattdessen:

AddListFlow: fünfter Button "Priorisiert" → neuer CreatePriorityTodoListDialog (Titel +
Faktor-Eingabe mit Default 1.1).
PriorityMatrixPage (neu, gerendert wenn list.type === 'Priority'):
- Ansichts-Toggle mit zwei Optionen: "Liste" (V1, klassisch nach Formel sortiert) und "Karte
  (kommt bald)" — der Karten-Button ist sichtbar, aber deaktiviert; ein title erklärt den
  Grund. Damit ist der Toggle-Slot schon in der UI vorhanden und die Follow-up-Story tauscht nur
  den Panel-Inhalt aus, ohne die Page-Shell erneut anzufassen.
- Klassische Ansicht sortiert per Urgency + Faktor × Importance absteigend. Keine
  Kategorie-Gruppierung (AC explizit — "würde die Formel-Sortierung durchbrechen").
- Label-Filter (bestehende Chip-Komponente aus Standard-TodoList wiederverwendet).
- Pro-Todo-Zeile zeigt Titel + Urgency/Importance-Zahlen + berechneten Score als kleines
  Neben-Chip; ansonsten dieselbe TodoRow-Komponente wie Standard-Listen (Checkbox,
  Fälligkeit, Assignee, Subtasks-Badge, Kommentar-Badge, Recurrence-Badge — alle unverändert).
CreatePriorityTodoDialog (neu, ersetzt die Inline-TodoInput-Zeile bei Priority-Listen —
AC: "eigenes Modal, nicht die kleine Eingabezeile unten"):
- Titel-Eingabefeld.
- Zwei Number-Inputs Urgency/Importance, Default 50 / 50.
- Klickbare Mini-2D-Karte (SVG-Grid 100×100 skaliert auf ~200×200 Pixel): ein Klick setzt beide
  Zahlen entsprechend der Klick-Koordinate; umgekehrt aktualisiert eine Änderung an den
  Zahlen-Inputs die Punkt-Position. Read-only-Karte in V1 — keine Drag-Interaktion (das ist
  der explizit deferrte Teil).
- Label-Picker inkl. "+ Neues Label anlegen"-Button (bestehende LabelPickerPopover
  wiederverwendet, falls vorhanden; sonst als Teil dieser Story neu, aber leichtgewichtig).
Faktor-Einstellung: einfaches Number-Input auf der PriorityMatrixPage (oben rechts,
neben dem Ansichts-Toggle), auf blur gespeichert via SetPriorityMatrixFactorCommand;
Owner-only sichtbar.
Urgency/Importance nachträglich editieren: über einen kleinen "Ändern"-Link neben den
Zahlen in der Listenzeile → öffnet dasselbe Zwei-Zahlen-Modal (kleinere Wiederverwendung des
Create-Dialog-Inhalts) → speichert via SetTodoUrgencyImportanceCommand. Ohne diesen Editier-
Weg wäre die Formel-Neujustierung nur durch Löschen und Neuanlegen möglich, was den ganzen
Nutzen der Liste konterkariert.

Explizit deferred: Follow-up-Story `#91b`

Volle 2D-Karten-Ansicht mit Drag-to-Reposition eines bestehenden Punkts. Aktuell nur
Placeholder im Toggle. Grund: die Drag-Interaktion (Touch + Desktop, Achsen-Clamping,
Live-Persistierung während des Drags, Kollisionsvermeidung eng beieinander liegender Punkte,
visuelles Label bei Hover/Focus, Screen-Reader-Alternative) ist der Löwenanteil des UI-Aufwands
der Story und trägt gleichzeitig das meiste Fehlerrisiko — sinnvoller als eigene Folge-Story,
sobald V1 in echter Nutzung ist und der genaue Bedarf klar wird (z.B. "wird die Karte auf
Mobile überhaupt praktisch genutzt?"). Backend, Datenmodell, Sortierlogik und
SetTodoUrgencyImportanceCommand sind bereits in V1 vorhanden — #91b ist damit rein
Frontend-Arbeit ohne API/DB-Erweiterung.

Security-Vorprüfung

Keine neuen Authorisierungs-Pfade:

CreateTodoListCommand erweitert um Typ-Parameter — bestehender Auth-Check unverändert (der
User erstellt seine eigene Liste, kein neuer Fremdzugriff möglich).
CreateTodoCommand erweitert um Urgency/Importance — Handler ruft bestehenden
AuthorizeTodoListAccessQuery (Mitglied darf Todos anlegen), zusätzlich Type = Priority-Check.
SetTodoUrgencyImportanceCommand — spiegelt SetTodoDueDateCommand (Mitglieds-Access, keine
Owner-Restriktion — jeder Nutzer darf jedes Todo einer Liste bearbeiten, dieselbe Regel wie für
Titel/Beschreibung/Fälligkeit).
SetPriorityMatrixFactorCommand — Owner-only, spiegelt SetTodoListAppearanceCommand. Faktor
ist pro-Liste-Konfig, nicht pro-Ansicht — Member sollen nicht die Formel für alle anderen ändern
können.

Numerische Ranges werden per Vogen im Serialisierungspfad validiert (Ungültige Werte → 400 bevor
der Handler läuft). Keine Injection-Vektoren (reine Zahlen/Enum-Werte).

Test-Strategie

Backend-Handler-Tests: CreateTodoListCommandHandler für neuen Type-Parameter,
CreateTodoCommandHandler für Urgency/Importance (inkl. Fehler bei Standard-Liste),
SetTodoUrgencyImportanceCommandHandler, SetPriorityMatrixFactorCommandHandler (Owner-only-
Ablehnung).
Frontend-Unit: PriorityMatrixPage (Sortierung, Label-Filter, Toggle-Placeholder-Zustand),
CreatePriorityTodoDialog (Mini-Karten-Klick synchronisiert Zahlen, Label-Auswahl,
Submit-Payload), CreatePriorityTodoListDialog (Faktor-Default, Erstellung).
E2E: erstelle Priority-Liste → lege drei Todos mit unterschiedlichen Urgency/Importance an →
prüfe Reihenfolge nach Formel → ändere Faktor → prüfe geänderte Reihenfolge → editiere ein
Todo → prüfe neue Position.

**design** (`91_priority_matrix_list_type_design.md`) # Design: `#91` — Priorisierte Liste (Dringend/Wichtig-Matrix) ## Kernentscheidung: Variante der Todo-Liste, nicht Sibling-Entity `TodoListEntity` bekommt eine neue `Type`-Spalte (`Standard | Priority`), `TodoEntity` bekommt zwei nullable Zusatzfelder (`Urgency`, `Importance`) und `TodoListEntity` ein nullable `PriorityMatrixFactor` — **kein neuer Entity-Baum**. **Begründung:** `#91` verlangt explizit "volle bestehende Todo-Feature-Palette bleibt erhalten: Fälligkeitsdatum, Zuweisung, Subtasks/Checkliste, Kommentare, Wiederholung, Kategorien". Eine Sibling-Entity nach dem Vorbild von `#93` (Masterpackliste) müsste jedes dieser Features neu bauen — das widerspricht der AC direkt. `Priority` ist inhaltlich eine *Variante* der Todo-Liste (dieselben Todos, andere Anordnung/Zusatzachsen), nicht eine strukturell andere Domain wie Shopping/Pantry/Masterpack. Damit weicht diese Story bewusst von `#89`'s "kein `ListType`-Enum/-Spalte"-Ruling ab. `#89` selbst hat diese Öffnung offengelassen: *"Für `#91`–94 ist das eine eigene künftige Architect-Entscheidung — spekulative Enum-Werte für noch nicht gebaute Typen würden jetzt nur Risiko ohne Nutzen hinzufügen (YAGNI)."* Der Enum-Wert wird hier für einen konkret gebauten Typ eingeführt, nicht spekulativ; der YAGNI-Grund entfällt damit. ## Schema-Änderungen ### `TodoListEntity` - `Type` — neuer `TodoListType`-Enum (`Standard = 0, Priority = 1`), NOT NULL, default `Standard`. - `PriorityMatrixFactor` — nullable `double`, nur bei `Type = Priority` gesetzt, Default `1.1`. Range-Validation im VO (0.0 < factor ≤ 10.0). Nullable statt "nur ignoriert" damit der Zustand "keine Priorisierungs-Liste" strukturell unmissverständlich bleibt und ein späterer Type-Wechsel (aktuell nicht vorgesehen — Type ist bei Erstellung fixiert) nicht magisch einen Faktor mitführt. ### `TodoEntity` - `Urgency` — nullable `TodoUrgency` (1–100), gesetzt nur bei Todos auf einer Priority-Liste. - `Importance` — nullable `TodoImportance` (1–100), gesetzt nur bei Todos auf einer Priority-Liste. Beide nullable, weil dieselbe `TodoEntity`-Tabelle Todos beider List-Typen enthält. Bei Standard-Listen bleiben die Felder `NULL` und werden vom Frontend nicht abgefragt/angezeigt. Die bestehende `Priority`-Spalte (`Low/Normal/High`) bleibt strukturell erhalten und wird für Priority-Listen vom Frontend schlicht nicht mehr angeboten — AC-konform ("bei diesem Typ nicht verwendet/angezeigt"). ## Neue Vogen-VOs - `TodoListType` (Enum, `Standard | Priority`). - `TodoUrgency` (int, 1–100). - `TodoImportance` (int, 1–100). - `PriorityMatrixFactor` (double, 0.0 < x ≤ 10.0). Bereich 1–100 statt 0–100 spiegelt die AC-Formulierung wörtlich ("auf einer Skala von 1–100"). ## Neue/erweiterte Commands & Queries - `CreateTodoListCommand` — bekommt optionalen `Type`-Parameter (default `Standard`) und optionalen `PriorityMatrixFactor` (nur bei `Type = Priority` gesetzt). Zwei bestehende Handler-Aufrufe (`CreateTodoListCommandHandler`, dessen Tests, Frontend-`CreateListDialog`) auf die erweiterte Signatur ziehen. - `CreateTodoCommand` — bekommt optionale `Urgency`/`Importance`-Parameter, die nur gesetzt werden dürfen wenn die Ziel-Liste `Type = Priority` hat (Handler validiert). Bei Standard-Listen MÜSSEN sie null sein; bei Priority-Listen SOLLEN sie gesetzt sein (nicht zwingend im Handler erzwungen — Frontend schickt sie immer; sonst greift der Default 50/50 der V1-Semantik). - Neu: `SetTodoUrgencyImportanceCommand` (id + urgency + importance). Muss geprüft werden: die Ziel-Liste ist vom Typ `Priority`; sonst 400. - Neu: `SetPriorityMatrixFactorCommand` (id + factor). Owner-only (spiegelt `SetTodoListAppearanceCommand`'s Owner-Regel — pro-Liste-Konfig). ## Migration Ein Migration-File mit drei DDL-Schritten: 1. `ALTER TABLE "TodoListEntity" ADD COLUMN "Type" TEXT NOT NULL DEFAULT 'Standard'`. 2. `ALTER TABLE "TodoListEntity" ADD COLUMN "PriorityMatrixFactor" DOUBLE PRECISION NULL`. 3. `ALTER TABLE "TodoEntity" ADD COLUMN "Urgency" INTEGER NULL`, `ALTER TABLE "TodoEntity" ADD COLUMN "Importance" INTEGER NULL`. Kein Backfill nötig — Bestandslisten sind alle `Type = Standard`, Todos haben `NULL` Urgency/Importance. ## Frontend — V1-Scope Menschlicher PO hat 2026-08-09 in der laufenden Session entschieden, die volle 2D-Scatter-Ansicht mit Drag-to-Reposition in einen Follow-up zu ziehen. V1 liefert stattdessen: - **AddListFlow:** fünfter Button "Priorisiert" → neuer `CreatePriorityTodoListDialog` (Titel + Faktor-Eingabe mit Default 1.1). - **PriorityMatrixPage** (neu, gerendert wenn `list.type === 'Priority'`): - Ansichts-Toggle mit *zwei* Optionen: "Liste" (V1, klassisch nach Formel sortiert) und "Karte (kommt bald)" — der Karten-Button ist sichtbar, aber deaktiviert; ein `title` erklärt den Grund. Damit ist der Toggle-Slot schon in der UI vorhanden und die Follow-up-Story tauscht nur den Panel-Inhalt aus, ohne die Page-Shell erneut anzufassen. - Klassische Ansicht sortiert per `Urgency + Faktor × Importance` absteigend. **Keine Kategorie-Gruppierung** (AC explizit — "würde die Formel-Sortierung durchbrechen"). - Label-Filter (bestehende Chip-Komponente aus Standard-`TodoList` wiederverwendet). - Pro-Todo-Zeile zeigt Titel + Urgency/Importance-Zahlen + berechneten Score als kleines Neben-Chip; ansonsten dieselbe `TodoRow`-Komponente wie Standard-Listen (Checkbox, Fälligkeit, Assignee, Subtasks-Badge, Kommentar-Badge, Recurrence-Badge — alle unverändert). - **CreatePriorityTodoDialog** (neu, ersetzt die Inline-`TodoInput`-Zeile bei Priority-Listen — AC: "eigenes Modal, nicht die kleine Eingabezeile unten"): - Titel-Eingabefeld. - Zwei Number-Inputs Urgency/Importance, Default 50 / 50. - Klickbare Mini-2D-Karte (SVG-Grid 100×100 skaliert auf ~200×200 Pixel): ein Klick setzt beide Zahlen entsprechend der Klick-Koordinate; umgekehrt aktualisiert eine Änderung an den Zahlen-Inputs die Punkt-Position. **Read-only-Karte in V1** — keine Drag-Interaktion (das ist der explizit deferrte Teil). - Label-Picker inkl. "+ Neues Label anlegen"-Button (bestehende `LabelPickerPopover` wiederverwendet, falls vorhanden; sonst als Teil dieser Story neu, aber leichtgewichtig). - **Faktor-Einstellung:** einfaches Number-Input auf der `PriorityMatrixPage` (oben rechts, neben dem Ansichts-Toggle), auf `blur` gespeichert via `SetPriorityMatrixFactorCommand`; Owner-only sichtbar. - **Urgency/Importance nachträglich editieren:** über einen kleinen "Ändern"-Link neben den Zahlen in der Listenzeile → öffnet dasselbe Zwei-Zahlen-Modal (kleinere Wiederverwendung des Create-Dialog-Inhalts) → speichert via `SetTodoUrgencyImportanceCommand`. Ohne diesen Editier- Weg wäre die Formel-Neujustierung nur durch Löschen und Neuanlegen möglich, was den ganzen Nutzen der Liste konterkariert. ## Explizit deferred: Follow-up-Story `#91b` - **Volle 2D-Karten-Ansicht mit Drag-to-Reposition eines bestehenden Punkts.** Aktuell nur Placeholder im Toggle. Grund: die Drag-Interaktion (Touch + Desktop, Achsen-Clamping, Live-Persistierung während des Drags, Kollisionsvermeidung eng beieinander liegender Punkte, visuelles Label bei Hover/Focus, Screen-Reader-Alternative) ist der Löwenanteil des UI-Aufwands der Story und trägt gleichzeitig das meiste Fehlerrisiko — sinnvoller als eigene Folge-Story, sobald V1 in echter Nutzung ist und der genaue Bedarf klar wird (z.B. "wird die Karte auf Mobile überhaupt praktisch genutzt?"). Backend, Datenmodell, Sortierlogik und `SetTodoUrgencyImportanceCommand` sind bereits in V1 vorhanden — `#91b` ist damit rein Frontend-Arbeit ohne API/DB-Erweiterung. ## Security-Vorprüfung Keine neuen Authorisierungs-Pfade: - `CreateTodoListCommand` erweitert um Typ-Parameter — bestehender Auth-Check unverändert (der User erstellt seine eigene Liste, kein neuer Fremdzugriff möglich). - `CreateTodoCommand` erweitert um Urgency/Importance — Handler ruft bestehenden `AuthorizeTodoListAccessQuery` (Mitglied darf Todos anlegen), zusätzlich `Type = Priority`-Check. - `SetTodoUrgencyImportanceCommand` — spiegelt `SetTodoDueDateCommand` (Mitglieds-Access, keine Owner-Restriktion — jeder Nutzer darf jedes Todo einer Liste bearbeiten, dieselbe Regel wie für Titel/Beschreibung/Fälligkeit). - `SetPriorityMatrixFactorCommand` — Owner-only, spiegelt `SetTodoListAppearanceCommand`. Faktor ist pro-Liste-Konfig, nicht pro-Ansicht — Member sollen nicht die Formel für alle anderen ändern können. Numerische Ranges werden per Vogen im Serialisierungspfad validiert (Ungültige Werte → 400 bevor der Handler läuft). Keine Injection-Vektoren (reine Zahlen/Enum-Werte). ## Test-Strategie - Backend-Handler-Tests: `CreateTodoListCommandHandler` für neuen Type-Parameter, `CreateTodoCommandHandler` für Urgency/Importance (inkl. Fehler bei Standard-Liste), `SetTodoUrgencyImportanceCommandHandler`, `SetPriorityMatrixFactorCommandHandler` (Owner-only- Ablehnung). - Frontend-Unit: `PriorityMatrixPage` (Sortierung, Label-Filter, Toggle-Placeholder-Zustand), `CreatePriorityTodoDialog` (Mini-Karten-Klick synchronisiert Zahlen, Label-Auswahl, Submit-Payload), `CreatePriorityTodoListDialog` (Faktor-Default, Erstellung). - E2E: erstelle Priority-Liste → lege drei Todos mit unterschiedlichen Urgency/Importance an → prüfe Reihenfolge nach Formel → ändere Faktor → prüfe geänderte Reihenfolge → editiere ein Todo → prüfe neue Position.