fix(#330): tracking-todos in dedizierter Pakete-Liste #334

Merged

admin-mrrm merged 1 commit from fix/330-tracking-todo-pakete-liste into main

2026-05-18 20:23:37 +02:00

admin-mrrm commented

2026-05-18 20:17:54 +02:00

Owner

Closes #330.

Was

Einzeiler-Fix in TrackingTodoWriterService.ensureTodoList(): zusätzlicher title === DEFAULT_TODO_LIST_TITLE-Check, damit nur die dedizierte "Pakete"-Liste wiederverwendet wird (statt der ersten beliebigen Todo-Liste).

Wieso kein Metadata-Flag

Issue erwähnt optional system: tracking-todos als saubereren Marker — würde Schema-Migration brauchen + den User-Use-Case "Liste umbenennen" abdecken. Scope hier bewusst klein. Wenn der User die Liste umbenennt, legt der Service eine neue "Pakete" daneben an (akzeptabel, sichtbar, leicht zu erklären).

Tests

Bestehender Test nutzt existierende Todo-Liste statt neue zu erstellen zementierte den Bug — auf "Pakete"-Titel korrigiert.
Neuer Test legt "Pakete"-Liste neu an wenn nur fremde Todo-Liste existiert (Bug #330) deckt den Reproschritt aus dem Issue ab.
5/5 Tests grün, pnpm typecheck clean.

Backfill

Nicht in diesem PR — User mit bereits falsch eingeordneten Todos bleiben so. Falls relevant: separates Folge-Issue (Migration: alle Items mit Title-Pattern "Paket [...] (TN)" in fremden Todo-Listen → eigene "Pakete"-Liste verschieben).

Test plan

vitest grün via CI
Manuell (optional): User mit nur "Alltag"-Liste anlegen, Tracking auf Delivered triggern → "Pakete" wird neu angelegt, Todo dort

Closes #330. ## Was Einzeiler-Fix in `TrackingTodoWriterService.ensureTodoList()`: zusätzlicher `title === DEFAULT_TODO_LIST_TITLE`-Check, damit nur die dedizierte "Pakete"-Liste wiederverwendet wird (statt der ersten beliebigen Todo-Liste). ## Wieso kein Metadata-Flag Issue erwähnt optional `system: tracking-todos` als saubereren Marker — würde Schema-Migration brauchen + den User-Use-Case "Liste umbenennen" abdecken. Scope hier bewusst klein. Wenn der User die Liste umbenennt, legt der Service eine neue "Pakete" daneben an (akzeptabel, sichtbar, leicht zu erklären). ## Tests - Bestehender Test `nutzt existierende Todo-Liste statt neue zu erstellen` zementierte den Bug — auf "Pakete"-Titel korrigiert. - Neuer Test `legt "Pakete"-Liste neu an wenn nur fremde Todo-Liste existiert (Bug #330)` deckt den Reproschritt aus dem Issue ab. - 5/5 Tests grün, `pnpm typecheck` clean. ## Backfill Nicht in diesem PR — User mit bereits falsch eingeordneten Todos bleiben so. Falls relevant: separates Folge-Issue (Migration: alle Items mit Title-Pattern `"Paket [...] (TN)"` in fremden Todo-Listen → eigene "Pakete"-Liste verschieben). ## Test plan - [ ] vitest grün via CI - [ ] Manuell (optional): User mit nur "Alltag"-Liste anlegen, Tracking auf `Delivered` triggern → "Pakete" wird neu angelegt, Todo dort

admin-mrrm added 1 commit

2026-05-18 20:17:54 +02:00

fix(#330 ): tracking-todos landen in dedizierter "Pakete"-Liste

continuous-integration/drone/push Build is passing

Details

continuous-integration/drone/pr Build is passing

Details

64611fbda4

ensureTodoList() filterte nur über l.type==='todo' und nahm die
erste beliebige Todo-Liste. Wenn der User bereits eine andere
Todo-Liste (z.B. "Alltag") hatte, landeten alle Auto-Todos vom
TrackingSyncCron dort vermischt rein.

Jetzt zusätzlicher title===DEFAULT_TODO_LIST_TITLE-Check. Damit
wird nur die "Pakete"-Liste wiederverwendet; existiert sie nicht,
wird sie angelegt — auch wenn andere Todo-Listen schon da sind.

Tests: bestehender Reuse-Test korrigiert (assertete den Bug); neuer
Test 'legt "Pakete" neu an wenn nur fremde Todo-Liste existiert'.