-
v0.6.6-rc31
Stablereleased this
2026-06-23 08:10:00 +02:00 | 18 commits to main since this releaseSchließ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
-
Source code (ZIP)
1 download
-
Source code (TAR.GZ)
1 download
-
mrrmlab--1987d53.apk
2 downloads ·
2026-06-23 08:29:25 +02:00 · 151 MiB
-
v0.6.6-rc30
Stablereleased this
2026-06-23 07:07:22 +02:00 | 19 commits to main since this releaseVerdrahtet 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
-
Source code (ZIP)
1 download
-
Source code (TAR.GZ)
1 download
-
mrrmlab--9bb0cc9.apk
2 downloads ·
2026-06-23 07:26:42 +02:00 · 151 MiB
-
v0.6.6-rc29
Stablereleased this
2026-06-18 00:19:09 +02:00 | 23 commits to main since this releaseSystematische 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
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
1 download
-
mrrmlab--4e7c555.apk
3 downloads ·
2026-06-18 00:37:34 +02:00 · 151 MiB
-
v0.6.6-rc28
Stablereleased this
2026-06-16 12:44:53 +02:00 | 29 commits to main since this releasePhase 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
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
1 download
-
mrrmlab--3b0b72a.apk
1 download ·
2026-06-16 13:12:38 +02:00 · 151 MiB
-
v0.6.6-rc27
Stablereleased this
2026-06-16 07:54:17 +02:00 | 32 commits to main since this releaseSchließ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
-
Source code (ZIP)
1 download
-
Source code (TAR.GZ)
2 downloads
-
mrrmlab--a1fcd80.apk
2 downloads ·
2026-06-16 08:17:46 +02:00 · 151 MiB
-
v0.6.6-rc26
Stablereleased this
2026-06-16 07:02:45 +02:00 | 37 commits to main since this releaseErste 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
-
Source code (ZIP)
1 download
-
Source code (TAR.GZ)
3 downloads
-
mrrmlab--efc1970.apk
2 downloads ·
2026-06-16 07:26:15 +02:00 · 151 MiB
-
v0.6.6-rc25
Stablereleased this
2026-06-15 21:47:45 +02:00 | 42 commits to main since this releaseLetzte 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
-
Source code (ZIP)
3 downloads
-
Source code (TAR.GZ)
2 downloads
-
mrrmlab--99f15c1.apk
2 downloads ·
2026-06-15 22:11:15 +02:00 · 151 MiB
-
v0.6.6-rc24
Stablereleased this
2026-06-15 09:08:39 +02:00 | 46 commits to main since this releaseErste 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
-
Source code (ZIP)
1 download
-
Source code (TAR.GZ)
2 downloads
-
mrrmlab--e8d5e5c.apk
6 downloads ·
2026-06-15 09:31:48 +02:00 · 151 MiB
-
v0.6.6-rc23
Stablereleased this
2026-06-14 11:48:17 +02:00 | 51 commits to main since this releaseHotfix 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
-
Source code (ZIP)
1 download
-
Source code (TAR.GZ)
1 download
-
mrrmlab--846bad2.apk
3 downloads ·
2026-06-14 12:11:19 +02:00 · 151 MiB
-
v0.6.6-rc22
Stablereleased this
2026-06-14 02:12:53 +02:00 | 55 commits to main since this releaseSchließ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
-
Source code (ZIP)
1 download
-
Source code (TAR.GZ)
3 downloads
-
mrrmlab--23e982d.apk
4 downloads ·
2026-06-14 02:39:34 +02:00 · 151 MiB