• v0.6.6-rc31 1987d53f28

    v0.6.6-rc31
    All checks were successful
    continuous-integration/drone/push Build is passing
    continuous-integration/drone/pr Build is passing
    continuous-integration/drone/tag Build is passing
    Stable

    admin-mrrm released this 2026-06-23 08:10:00 +02:00 | 18 commits to main since this release

    Schließt Issue #452: Auto-Indexing-on-Mutation ist jetzt vollständig aktiv. Der Code-Level-Wireup war seit rc30 fertig (_layout.tsx publiziert via onListSourceChange in die DataSources, IndexingService.start() subscribed beim /search-Mount). Dieses RC aktiviert den Maestro-Smoke in der Auto-Trigger-Variante: die Phase2-smoke läuft jetzt ohne manuellen 'Jetzt indexieren'-Tap und bestätigt, dass Quellen >= 1 nach einer Listenerstellung automatisch erscheint. Stale-Kommentar in search-ports.ts aktualisiert.

    Highlights

    • phase2-mutation-observer-smoke.yaml: Auto-Trigger-Variante — kein 'Jetzt indexieren'-Tap mehr, Quellen >= 1 erscheint automatisch nach Listenerstellung
    • search-ports.ts: debugIndexAll-Kommentar auf aktuellen Stand gebracht (Wireup ist seit rc30 aktiv)
    Downloads
  • v0.6.6-rc30 9bb0cc9dfc

    v0.6.6-rc30
    All checks were successful
    continuous-integration/drone/push Build is passing
    continuous-integration/drone/tag Build is passing
    continuous-integration/drone/pr Build is passing
    Stable

    admin-mrrm released this 2026-06-23 07:07:22 +02:00 | 19 commits to main since this release

    Verdrahtet den initial-vector-index Background-Task (expo-task-manager) und schließt damit die KI-Foundation Phase 2 ab. Der Embedder läuft jetzt automatisch im Hintergrund, sobald das Gerät lädt und im WLAN ist — kein manueller Jetzt-indexieren-Button mehr nötig. listSourceIds gibt echte IDs zurück (Shopping-Listen + Notizen), der INITIAL_INDEX_TASK ruft indexingService.runInitialIndex() auf. DebugIndexBar-Disclaimer entfernt. Maestro phase2-mutation-observer-smoke auf deutsche UI-Strings aktualisiert. Roadmap-Bookkeeping: rc1–rc9 auf done gesetzt (waren stale-next).

    Highlights

    • batch-task.ts: INITIAL_INDEX_TASK — läuft maximal 1×/Tag bei Ladung+Wifi, ruft indexingService.runInitialIndex() über SearchPorts-Singleton
    • search-ports.ts: listSourceIds gibt echte Shopping-Listen- und Notiz-IDs zurück (statt leere Liste)
    • DebugIndexBar: Disclaimer Auto-Indexing kommt erst mit der nächsten Iteration entfernt
    • Maestro phase2-mutation-observer-smoke.yaml: New list name → Listenname, Add → Hinzufügen (rc29-Regression behoben)
    • roadmap.json: rc1–rc9 Bookkeeping-Lücke geschlossen (status: done)
    Downloads
  • v0.6.6-rc29 4e7c555776

    v0.6.6-rc29
    All checks were successful
    continuous-integration/drone/push Build is passing
    continuous-integration/drone/tag Build is passing
    Stable

    admin-mrrm released this 2026-06-18 00:19:09 +02:00 | 23 commits to main since this release

    Systematische UX-Analyse der App mit anschließender Behebung von 13 identifizierten Lücken in drei Prioritätsstufen. Kritisch: Löschen ohne Bestätigung (Listen + Projekte) per Alert.alert abgesichert. Mittel: Einstellungen im Mobile-Drawer zugänglich, Web-Einstellungen zeigt echten Index-Screen statt Redirect, Planner-Feedback nach 'Tag jetzt planen', Habit-Datumseingabe mit Inline-Validierung, Mail-Review Done-State mit Zurück-CTA, Mobile Listen-Screen mit Geschäfte-Link. Klein: ICS-URLs nicht mehr abgeschnitten (selectable), Habit-Schnellauswahl-Buttons (täglich/wöchentlich/monatlich), Archiv-FAB-Spacer verhindert Überlappung mit letztem Item. Alle feature-lists-UI-Strings auf Deutsch. Debug-Bar in Suche hinter DEV-Guard.

    Highlights

    • Alert.alert-Confirm vor Listen-Löschen ('wirklich löschen?') und Projekt-Löschen (inkl. Schritte-Anzahl im Text) — kein unbeabsichtigtes Datenverlust mehr
    • Mobile Drawer: Einstellungen-Eintrag in NAV_ITEMS — bisher nur über Profil-Icon erreichbar
    • Web /einstellungen: echter Index-Screen mit allen Kategorien statt Redirect auf /einstellungen/mail
    • Day-Planner: Statuszeile nach 'Tag jetzt planen' zeigt 'X Einträge geplant' / 'Keine Candidates verfügbar'
    • Habits: Inline-Fehlermeldung bei ungültigem Datum/Intervall + Preset-Buttons Täglich/Wöchentlich/Monatlich
    • feature-lists: alle englischen UI-Strings auf Deutsch (Listenname, Hinzufügen, Einkaufen/Notizen, Aufgabentitel, Fälligkeitsdatum, Niedrig/Hoch, Speichern/Abbrechen)
    • Mobile Suche: DebugIndexBar hinter DEV-Guard (war in Release-APKs sichtbar)
    • Archiv: FlatList-Footer-Spacer (88px) verhindert FAB-Überlappung; Kalender-URL selectable statt abgeschnitten
    Downloads
  • v0.6.6-rc28 3b0b72a357

    v0.6.6-rc28
    All checks were successful
    continuous-integration/drone/push Build is passing
    continuous-integration/drone/tag Build is passing
    Stable

    admin-mrrm released this 2026-06-16 12:44:53 +02:00 | 29 commits to main since this release

    Phase 3 von Epic #360 (Projekte als Candidate-Source). Mehrstufige Vorhaben mit geordneten Schritten werden zu Candidates mit linearer dependsOn-Chain — der Planner v1-DAG (rc26) sorgt dafür, dass Schritt N+1 erst nach Schritt N geplant wird. Im Unterschied zu Habits ist die Spawn-Logik nicht zeitgesteuert: Beim Anlegen eines Projekts werden alle Step-Candidates synchron geschrieben, kein Cron nötig. Damit ist die rule-based-Source-Sammlung (Tracking, Calendar, Habits, Projects) vollständig — verbleibende Sources Mail→Candidate (#178) und Planner v2 (LLM) sitzen beide hinter Epic #122 (KI-Foundation).

    Highlights

    • shared-types: projectSchema, projectStepSchema, createProjectRequestSchema, updateProjectRequestSchema — Single-Source-of-Truth-Contract
    • api-client: ProjectsResource mit list/create/update/delete + 5 Tests (inkl. Schema-Drift-Guard analog rc22-Lehrlauf)
    • API: projects-Tabelle (id, ownerSub, title, steps JSONB, archivedAt); ProjectCandidateWriterService spawnt Candidates synchron beim Create, idempotent via (ownerSub, source, sourceRef)-Unique-Constraint
    • dependsOn-Chain: Step i abhängig von Candidate(Step i-1) — Planner v1 stellt Reihenfolge sicher; Conflict-Lookup hält die Chain auch beim Re-Spawn intakt
    • feature-day-planner: ProjectsSettingsScreen (Tamagui cross-platform, multiline-Steps-Textarea) + 4 TanStack-Query-Hooks (useProjects/useCreateProject/useUpdateProject/useDeleteProject)
    • Web /einstellungen/projekte + Sidebar-Eintrag 'Projekte'; Mobile einstellungen/projekte.tsx + Drawer-Index-Eintrag
    • Tests: 13 neue Unit-Tests (ProjectsService 8 + Writer 5), 5 neue Integration-Tests (POST→Candidates+dependsOn-Chain, archive/restore, delete, validation), 5 api-client-Tests — alle grün
    • v1-UI-Out-of-Scope (Folge): Inline-Step-Edit, Step-Hinzufügen-Nach-Create, Per-Step-Duration-UI, geplante-vs-archivierte-Sektionen
    Downloads
  • v0.6.6-rc27 a1fcd807b0

    v0.6.6-rc27
    All checks were successful
    continuous-integration/drone/push Build is passing
    continuous-integration/drone/tag Build is passing
    Stable

    admin-mrrm released this 2026-06-16 07:54:17 +02:00 | 32 commits to main since this release

    Schließt Phase 4 von Epic #360. Das Backend war seit ein paar Sprints fertig — habits-Tabelle, HabitsService/-Controller, HabitCandidateWriter, HabitSpawnerCron (stündlich) erzeugen Candidates aus due Habits. Was fehlte: UI zum Anlegen/Verwalten. rc27 schließt analog rc25 (Calendar Settings) die Lücke mit Einstellungen→Routinen (Web + Mobile).

    Highlights

    • shared-types: habitSchema, createHabitRequestSchema, updateHabitRequestSchema — Single-Source-of-Truth-Contract
    • api-client: HabitsResource mit list/create/update/delete + 5 Tests (inkl. Schema-Drift-Guard wie rc22-Lehrlauf)
    • feature-day-planner: HabitsSettingsScreen (Tamagui cross-platform) + 3 TanStack-Query-Hooks (useHabits/useCreateHabit/useDeleteHabit)
    • Web /einstellungen/habits + Sidebar-Eintrag 'Routinen'; Mobile einstellungen/habits.tsx + Drawer-Index-Eintrag
    • v1-UI-Out-of-Scope (Folge): Inline-Edit, RRULE-UI, Streak-Anzeige
    • Damit ist Phase 4 von #360 vollständig — Habits sind jetzt als regulär nutzbare Candidate-Source verfügbar
    Downloads
  • v0.6.6-rc26 efc1970c74

    v0.6.6-rc26
    All checks were successful
    continuous-integration/drone/push Build is passing
    continuous-integration/drone/tag Build is passing
    Stable

    admin-mrrm released this 2026-06-16 07:02:45 +02:00 | 37 commits to main since this release

    Erste Erweiterung über das v0-Heuristik-Niveau hinaus: Der Slot-Planner respektiert jetzt das dependsOn[]-Feld der Candidates. Bisher wurde es vom Schema gepflegt (Phase 1) aber vom Planner ignoriert — Abhängigkeiten wie 'Paket-Benachrichtigung lesen vor Postpaket abholen' wurden zufallsbasiert geplant. rc26 implementiert Kahn-Topologische-Sortierung mit Generationen, Zyklen-Erkennung (alle Beteiligten → overflow, kein Deadlock) und Cascade-Overflow (overflow-Dep ⇒ dependent-Candidate auch overflow). Externe Deps (already done, nicht im pending-Pool) werden als erfüllt behandelt. Innerhalb einer Generation greift die unveränderte v0-Logik: Location-Bucket + Priority-Sort + Event-Skip.

    Highlights

    • slot-plan.ts: Neue topoGenerations(candidates) liefert dependency-geordnete Generationen + cycle-Member-Liste
    • Kahn's Algorithmus: nur Deps INTO inputSet zählen — Deps auf bereits done/obsolete-Candidates (außerhalb pending-Pool) automatisch als satisfied gewertet
    • Cascade-Overflow: wenn ein Dep wegen latestAt/Tagesende overflow wird, geht der Dependent ebenfalls in overflow (Set-Tracking via overflowIds)
    • Cycle-Detection: was nach Kahn übrig bleibt = Zyklus-Member → overflow, kein Crash, kein Deadlock
    • 5 neue slot-plan.spec.ts Tests (dependsOn ordering reverse-of-id-sort, transitive c→b→a, cascade overflow, externe Deps, Cycle-Detection); 17/17 grün; alle 464 API-Tests grün
    • v1-Out-of-Scope (Folge-Issues): Habit-Context (braucht Habit-Source = Phase 4), plannedAfter/Before (Planner-Output kein -Input), Transit-Time zwischen Buckets, Time-of-Day Affinity
    Downloads
  • v0.6.6-rc25 99f15c16b0

    v0.6.6-rc25
    All checks were successful
    continuous-integration/drone/push Build is passing
    continuous-integration/drone/tag Build is passing
    Stable

    admin-mrrm released this 2026-06-15 21:47:45 +02:00 | 42 commits to main since this release

    Letzte offene Phase-5-Folgearbeit aus dem rc20-MVP: Der /heute-Screen kann seit rc20 Kalender-Events anzeigen, aber bisher gab es keine UI um einen ICS-Feed einzuhängen — nur per API-Direktcall möglich. rc25 schließt die Setup-Lücke mit einem Einstellungen→Kalender-Screen (Web + Mobile), der bestehende Feeds listet, Name+URL eingibt, manuell synct und entfernt. Backend (CalendarService + CalendarSyncService + 15-Min-Cron) war seit rc20 fertig. Damit ist Phase 5 vollständig: Empty-State (rc21), Re-Plan-Fix (rc21), Refresh-on-Focus (rc21), Hotfix Schema-Drift (rc23), Mark-Done (rc24), Kalender-Sync-Setup (rc25).

    Highlights

    • shared-types: calendarSubscriptionSchema, createCalendarSubscriptionRequestSchema, syncCalendarSubscriptionResponseSchema — Single-Source-of-Truth-Contract
    • api-client: CalendarResource mit list/create/patch/delete/sync + 5 Tests (inkl. Schema-Drift-Guard analog rc22-Lehrlauf)
    • feature-day-planner: CalendarSettingsScreen (Tamagui, cross-platform) + 4 TanStack-Query-Hooks; Invalidiert dayPlanner.today() bei Sync/Delete damit /heute sofort aktualisiert
    • Web /einstellungen/kalender + Sidebar-Eintrag; Mobile einstellungen/kalender.tsx + Drawer-Einstellungen-Index-Eintrag
    • Empty-State auf /heute bekommt dritten CTA 'Kalender verbinden' → /einstellungen/kalender (analog zu Mail/Todo aus rc21)
    • ICS-URL-Only Scope; OAuth/Outlook explizit out-of-scope für späteres Refinement
    Downloads
  • v0.6.6-rc24 e8d5e5c565

    v0.6.6-rc24
    All checks were successful
    continuous-integration/drone/push Build is passing
    continuous-integration/drone/tag Build is passing
    Stable

    admin-mrrm released this 2026-06-15 09:08:39 +02:00 | 46 commits to main since this release

    Erste Interaktion auf /heute: Tap auf den Done-Button entfernt das Item optimistisch von der Timeline. Backend bekommt einen idempotenten POST /candidates/:id/done-Endpoint, der lifecycleState in einer Transaktion auf 'done' setzt und — wenn source='todo' — list_items.data.done parallel im selben Tx mitführt (symmetrische Brücke aus #472). Damit bleiben /heute und die Todo-Liste in jeder Richtung konsistent: rc22 propagierte Todo-Änderungen Richtung Candidate, rc24 schließt den Rückweg. Architektur-Entscheidung per arch-bot konsultiert (arch-q #478, Option b: per-source inline backward-sync, kein Event-Bus für N=1). ADR 0001 §7 um Phase-1-Addendum erweitert. Undo bleibt explizit out-of-scope.

    Highlights

    • CandidatesService.markDone: db.transaction + SELECT FOR UPDATE + jsonb_set; cross-tenant guard über JOIN auf lists.owner_sub (list_items hat keine eigene ownerSub-Spalte); idempotent bei lifecycleState=done; 409 bei obsolete; 404 sonst
    • useMarkCandidateDone-Hook: TanStack Query Optimistic Update mit onMutate-Snapshot, onError-Rollback, onSettled-Invalidate
    • Tamagui ItemRow bekommt Done-Button mit accessibilityLabel='Erledigt:
    Downloads
  • v0.6.6-rc23 846bad25a9

    v0.6.6-rc23
    All checks were successful
    continuous-integration/drone/push Build is passing
    continuous-integration/drone/tag Build is passing
    Stable

    admin-mrrm released this 2026-06-14 11:48:17 +02:00 | 51 commits to main since this release

    Hotfix für rc22: Nach Release zeigte /heute auf dem Device 'Response from GET /planner/today did not match expected schema'. Ursache: In #472 wurde 'todo' zwar dem API-Drizzle-pgEnum (candidate_source) hinzugefügt, aber der parallel laufende shared-zod-Enum (candidateSourceSchema in @mrrmlab/shared-types/day-plan.ts) blieb unverändert — der Client warf jedes Todo-Candidate als unbekannten Source-Wert aus dem Schema. API-Integrationtests griffen nicht, weil supertest die Response nicht durch die Client-zod parsed; nur ein Web-Playwright-Test gegen /heute hätte das gefangen. rc23 fixt den Drift und sichert ihn mit Regression-Guard ab.

    Highlights

    • shared-types: candidateSourceSchema += 'todo' (Single-Source-of-Truth-Contract zwischen API und Client)
    • feature-day-planner: SOURCE_LABEL Record um 'todo': 'Todo' ergänzt — Tamagui-typecheck hätte den Drift früher gefangen, wenn shared-types in #472 aktualisiert worden wären (Typsystem hat es jetzt belegt)
    • Regression-Guard apps/web/e2e/heute-todo-flow.spec.ts: Playwright durchläuft Todo→Candidate→/heute end-to-end und schlägt fehl, sobald 'did not match expected schema' wieder auftritt
    Downloads
  • v0.6.6-rc22 23e982d692

    v0.6.6-rc22
    All checks were successful
    continuous-integration/drone/push Build is passing
    continuous-integration/drone/tag Build is passing
    Stable

    admin-mrrm released this 2026-06-14 02:12:53 +02:00 | 55 commits to main since this release

    Schließt die UX-Lücke aus rc21: Der Empty-State-CTA 'Manuelle Aufgabe erstellen' versprach, dass eine in der Todo-Liste angelegte Aufgabe automatisch auf /heute landet — aber Todos und Candidates waren zwei getrennte Datenmodelle. rc22 hängt die Brücke ein: Jedes Todo-List-Item mit gesetztem dueDate wird synchron als source='todo'-Candidate in die Planner-Pipeline geschrieben. Das geschieht im selben DB-Transaction-Schritt wie der Todo-Insert/Update/Delete (Sync-Source-Pattern aus arch-Entscheidung in #472). Heute-Datum + dueDate=heute → erscheint sofort auf /heute nach POST /planner/run. dueDate=null oder Item-Löschung → Candidate wird sauber entfernt. done=true → lifecycleState=done, der Planner ignoriert es. Architektur-Entscheidung per arch-bot konsultiert (Option a, Sync-Source-Pattern).

    Highlights

    • TodoCandidateWriterService: upsertFromTodo / removeForTodo mit ON CONFLICT (ownerSub, source='todo', sourceRef=list_item.id) DO UPDATE; Sub-Issue #472
    • ListsService.addItem / updateItem / removeItem laufen jetzt in db.transaction und rufen den Writer im selben Tx auf — kein Drift zwischen list_items und candidates möglich
    • Migration 0021: candidate_source += 'todo' (additiv, forward-only, rollback-safe)
    • 7 neue E2E-Integration-Tests (todo-candidate-flow.int-spec.ts) decken den ganzen Loop ab; API-Suite 459 unit + 91 integration tests grün
    Downloads