43 releases 51 tags

RSS feed

• v0.6.6-rc24 e8d5e5c565

  Compare

  v0.6.6-rc24 Stable

  admin-mrrm released this 2026-06-15 09:08:39 +02:00 | 80 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

  • 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 846bad25a9

  Compare

  v0.6.6-rc23 Stable

  admin-mrrm released this 2026-06-14 11:48:17 +02:00 | 85 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

  • 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 23e982d692

  Compare

  v0.6.6-rc22 Stable

  admin-mrrm released this 2026-06-14 02:12:53 +02:00 | 89 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

  • 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
• v0.6.6-rc21 6f07b87826

  Compare

  v0.6.6-rc21 Stable

  admin-mrrm released this 2026-06-13 16:42:10 +02:00 | 94 commits to main since this release

  Drei Folgearbeiten zum Day-Planner-MVP aus rc20, alle aus der rc20-Device-Validation hervorgegangen. (1) Empty-State mit Onboarding-CTAs: Wenn /heute leer ist, sieht der User jetzt eine Erklärung plus zwei Aktions-Buttons ['Manuelle Aufgabe erstellen' → Todo-Liste, 'Mail-Konto verbinden' → Mail-Setup] statt nur die Leerzeile. (2) Refresh-on-Focus: Web refetcht beim Tab-Wechsel zurück, Mobile via AppState-Bridge zum react-query focusManager beim Vordergrund-Hereinkommen — der Plan ist nach längerem Hintergrund-Liegen nicht mehr stale. (3) Re-Plan-Bug-Fix: POST /planner/run lieferte heutige bereits-planned Items nicht in der Response zurück, sodass die UI sie aus dem Cache verlor. planToday() läuft jetzt in einer DB-Transaktion mit Wipe-and-Replan-Semantik (heutige planned → pending → re-slot, done bleibt geschützt). Slotter mit id-Tiebreaker für stabile Slots bei identischem Pool. Architektur-Entscheidung per arch-bot konsultiert (Option a, Wipe-and-replan mit Stabilitäts-Refinement).

  Highlights

  • Empty-State: Onboarding-Karte mit zwei Action-Buttons (Web → /todo + /einstellungen/mail; Mobile → drawer/todo + /mail/new-account); Sub-Issue #463
  • Refresh-on-Focus: useDayPlan opt-in refetchOnWindowFocus; Mobile bridged AppState 'active' → focusManager.setFocused via apps/mobile/app/_layout.tsx; Sub-Issue #465
  • Re-Plan-Bug #461: planToday() in DB-Transaktion mit Demote-Step für heutige planned-Items; gestrige planned + done unangetastet; Slotter-Tiebreaker (priority, earliestAt, createdAt, id) für deterministische Slot-Zuordnung
  • Integration-Test-Idempotenz auf neue Wipe-and-Replan-Semantik umgestellt; API-Suite 452/452 grün

  Downloads

  • Source code (ZIP)
    3 downloads
  • Source code (TAR.GZ)
    3 downloads

  ---

  • mrrmlab--6f07b87.apk
    6 downloads · 2026-06-13 17:05:03 +02:00 · 151 MiB
• v0.6.6-rc20 1111ed62f7

  Compare

  v0.6.6-rc20 Stable

  admin-mrrm released this 2026-06-12 07:06:06 +02:00 | 106 commits to main since this release

  Der Day-Planner hat seinen ersten User-Touchpoint: ein /heute-Screen in Web und Mobile, der die heutigen Kalender-Termine und die vom PlannerService eingeplanten Candidate-Items auf einer gemeinsamen Timeline rendert. Backend (PlannerService, Candidate-Model, ADR 0001) war seit rc16 fertig, aber bisher ohne Client-Surface. Ein manueller 'Tag jetzt planen'-Button triggert POST /planner/run und aktualisiert die Liste. Folge-Phasen (Planner v1 regelbasiert, v2 LLM, Source-Done-Event-Bus aus ADR 0001 §7, Item-Klick → Mark-Done, Refresh-on-Focus) bleiben unter Epic #360 offen.

  Highlights

  • Neues Workspace-Paket @mrrmlab/feature-day-planner mit DayPlannerScreen, Provider und Hooks — spiegelt die Struktur der bestehenden Feature-Pakete (lists, tracking, shopping-list, day-planner)
  • shared-types: DayPlanDto/DayPlanItem/DayPlanEvent zod-Schemas; api-client: neue PlannerResource (GET /planner/today, POST /planner/run) mit 3 neuen Tests
  • Mobile: /heute-Drawer-Eintrag (Expo Router) — Web: /heute-Route + Sidebar-Eintrag (TanStack Router); Source-/Prioritäts-Badges pro Item, Events in eigenem Stil
  • Phase 5 (UI) von Epic #360 abgeschlossen — Epic bleibt für Planner v1/v2 und Event-Bus offen

  Downloads

  • Source code (ZIP)
    3 downloads
  • Source code (TAR.GZ)
    1 download

  ---

  • mrrmlab--1111ed6.apk
    6 downloads · 2026-06-12 07:32:50 +02:00 · 151 MiB
• v0.6.6-rc19 088ff78a5b

  Compare

  v0.6.6-rc19 Stable

  admin-mrrm released this 2026-06-09 00:09:37 +02:00 | 120 commits to main since this release

  Shopping-, Todo-, Notes- und Lists-Overview-Screen scrollen wieder. Der Screen-Container aus @mrrmlab/ui war ein YStack flex={1} ohne ScrollView, sodass auf Mobile Inhalte unterhalb des Viewports unerreichbar waren. Opt-in scrollable-Prop am Screen-Component aktiviert einen ScrollView-Wrapper; an den vier Listen-Screens angewendet.

  Highlights

  • Screen aus @mrrmlab/ui akzeptiert jetzt scrollable-Prop (opt-in)
  • ShoppingListScreen, TodoListScreen, NotesListScreen, ListsOverviewScreen mit scrollable
  • Andere Screens mit eigenem ScrollView (mail, archiv, einstellungen) unverändert

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    1 download

  ---

  • mrrmlab--088ff78.apk
    9 downloads · 2026-06-09 00:32:17 +02:00 · 151 MiB
• debug-rpi5 148e8c049c

  Compare

  Debug APK fuer rpi5 (auto) Pre-release

  admin-mrrm released this 2026-06-08 22:54:53 +02:00 | 122 commits to main since this release

  APP_VARIANT=development. NO Keycloak. Auto-overwritten per custom build. NOT FOR PROD.

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    1 download

  ---

  • mrrmlab-dev.apk
    6 downloads · 2026-06-08 22:54:54 +02:00 · 151 MiB
• v0.6.6-rc18 81080c8aaa

  Compare

  v0.6.6-rc18 Stable

  admin-mrrm released this 2026-06-08 07:27:43 +02:00 | 126 commits to main since this release

  Phase2-Validierung der Mutation→Publish-Kette wurde aus dem fragilen Maestro-Flow rausgezogen: 5 deterministische Unit-Tests in apps/mobile/tests/mutation-observer.test.tsx beweisen die useCreateList/Update/Delete → onSourceChange-Verkabelung gegen ein gemocktes ApiClient. Auf der Backend-Seite restauriert ein X-Dev-User-Header-Bypass in JwtAuthGuard die in den Code-Kommentaren dokumentierte Dev-Passthrough-Semantik — der no-Keycloak-Mobile-Build kann jetzt echte Mutationen gegen dev.api absetzen, ohne dass das prod-Deploy davon betroffen ist.

  Highlights

  • 5 Unit-Tests sperren die Mutation→onSourceChange-Verkabelung (Create/Update/Delete + Failure-Pfad + No-Callback-Provider)
  • JwtAuthGuard akzeptiert X-Dev-User: _{nur wenn NODE_ENV !== 'production' (4 Guard-Tests inkl. Prod-Bypass-Blocker)}
  • HttpClient.defaultHeaders-Option: Mobile-Dev-Build sendet X-Dev-User: dev-user wenn auth === null, Authorization aus getToken gewinnt weiterhin
  • Diagnostik-Counter (bumpA/B/C/D, ctx-Probe, mutation-trace.ts, Trace-Zeile in DebugIndexBar) entfernt — −67 Zeilen Diagnose-Overhead

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    1 download

  ---

  • mrrmlab--81080c8.apk
    5 downloads · 2026-06-08 07:44:54 +02:00 · 151 MiB
• v0.6.6-rc17 13dc5346ad

  Compare

  v0.6.6-rc17 Stable

  admin-mrrm released this 2026-06-07 19:14:32 +02:00 | 140 commits to main since this release

  Mutation-Hooks in feature-lists rufen jetzt einen optionalen onSourceChange-Callback im onSuccess. Mobile-Bootstrap fängt das ab und publisht in shopping-list- und note-DataSources — der Index füllt sich inkrementell beim Anlegen/Editieren/Löschen, der Debug-Button ist nicht mehr die einzige Quelle.

  Highlights

  • Neuer optionaler Prop onSourceChange auf ListsApiClientProvider
  • Alle 6 List-/Item-Mutation-Hooks rufen den Callback in onSuccess
  • Mobile-Bootstrap wired den Callback an einen DataSource-Bundle-Singleton (kein op-sqlite/onnxruntime beim App-Start)
  • 5 neue Tests in data-source-bundle.spec.ts sperren Singleton + Publish-Routing

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    1 download

  ---

  • mrrmlab--13dc534.apk
    6 downloads · 2026-06-07 19:33:40 +02:00 · 151 MiB
• v0.6.6-rc16 a6e8522116

  Compare

  v0.6.6-rc16 Stable

  admin-mrrm released this 2026-06-07 18:38:52 +02:00 | 143 commits to main since this release

  Xenova-ONNX-Export behält die Standard-BERT-3-Input-Signatur (input_ids, attention_mask, token_type_ids). E5/XLM-RoBERTa nutzt keine Segment-IDs in der Praxis — wir füttern jetzt einen Zeros-Tensor in token_type_ids, damit der ONNX-Graph zufrieden ist.

  Highlights

  • session.run() bekommt jetzt 3 Inputs statt 2
  • token_type_ids = Zeros-Tensor mit gleicher Shape wie input_ids
  • Spec-Test sperrt 3-Input-Verhalten

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    1 download

  ---

  • mrrmlab--a6e8522.apk
    8 downloads · 2026-06-07 18:56:34 +02:00 · 151 MiB