admin-mrrm/mrrmlabapp
1
0
Fork 0
Code Issues 15 Pull requests Projects Releases 40 Packages 5 Wiki Activity Actions

[Epic] Persönlicher KI-Assistent — Privacy-First On-Device Architektur #122

New issue
Open
opened 2026-04-27 00:36:43 +02:00 by admin-mrrm · 9 comments
admin-mrrm commented 2026-04-27 00:36:43 +02:00
Owner
Copy link

Vision

Die App wird langfristig zu einem persönlichen, lernenden Assistenten ausgebaut. Da dabei hochsensible Daten (Mails, Termine, Notizen, Verhalten) verarbeitet werden, gilt:

  • Verarbeitung findet ausschließlich on-device statt
  • Server speichert nur E2E-verschlüsselte Blobs — kein Klartextzugriff
  • Schlüssel verlassen das Gerät nie
  • Kein Drittanbieter-KI-SDK mit Telemetrie (kein Google AI Edge, kein OpenAI)

Architektur: Mehrstufige Pipeline

Kein Monolith-LLM für alles — stattdessen spezialisierte Schichten:

Input (Text, Mail, Sprache, Foto)
  ↓
[1] PII-Guard        — sensible Daten markieren, nie roh raussenden
  ↓
[2] Intent-Router    — schneller ML-Classifier (Was will der User?)
  ↓
[3] Extraktoren      — spezialisierte ONNX-Modelle pro Domain
  ↓
[4] RAG-Lookup       — persönliche Wissensbasis abrufen
  ↓
[5] LLM-Orchestrator — lokales LLM mit persönlichem Kontext
  ↓
[6] Action Layer     — Task / Termin / Erinnerung / Antwort erzeugen
  ↓
[Sync Layer]         — E2E-verschlüsselt auf Server

Schichten im Detail

Schicht Aufgabe Technologie Latenz
PII-Guard Namen, IBAN, Adressen erkennen & maskieren NER (ONNX) <30ms
Intent-Router Kategorie des Inputs bestimmen DistilBERT-tiny (ONNX) <50ms
Extraktoren Datum, Personen, Orte, Mengen extrahieren Fine-tuned NER (ONNX) <100ms
RAG-Lookup Relevante persönliche Einträge abrufen sqlite-vec + MiniLM-Embeddings <100ms
LLM-Orchestrator Reasoning, Antworten, Entscheidungen Phi-3 Mini / Gemma 2B (MLC-LLM) 1–3s

Die Modelle kommunizieren nicht direkt — jedes gibt strukturiertes JSON aus, das die nächste Schicht als Input bekommt.

Persönliches Lernen via RAG (kein LLM-Fine-Tuning)

LLMs on-device zu fine-tunen ist zu rechenintensiv. Stattdessen RAG + Feedback-Loop:

Persönliche Wissensbasis (lokal, verschlüsselt)

  • Alle Mails, Tasks, Termine, Notizen als Embeddings gespeichert
  • Embedding-Modell: all-MiniLM-L6-v2 → ONNX (~23 MB)
  • Vector Store: sqlite-vec (SQLite-Extension, kein Server nötig)

Feedback-Signale

  • User akzeptiert / lehnt Vorschlag ab → gewichteter Eintrag im Vector Store
  • Kleine Klassifikatoren (Intent, Extraktion) können on-device mit Nutzerfeedback nachtrainiert werden

Ergebnis

Das LLM „kennt" den User durch Kontext im Prompt — nicht durch veränderte Gewichte.

E2E-Verschlüsselung

Device                          Server
  ├── Rohdaten (Klartext)         ├── nur verschlüsselte Blobs
  ├── Verarbeitung (Klartext)     ├── kein Inhaltszugriff
  ├── Schlüssel (bleiben lokal)   └── reiner Sync/Backup-Store
  └── AES-256-GCM Verschlüsselung
        ↓
        → Upload
  • Schlüsselableitung: Argon2 aus PIN/Biometrie
  • Geräteübergreifende Sync: Schlüsselübertragung per QR-Code oder Passphrase
  • Server-Schema: nur user_id, blob_id, encrypted_data, updated_at

Beispielablauf

User sagt: „Erinnere mich morgen an das Meeting mit Lisa"

Intent-Router:  {"intent": "reminder"}
Extraktor:      {"person": "Lisa", "time": "tomorrow", "type": "meeting"}
RAG-Lookup:     [letzte 3 Meetings mit Lisa als Kontext]
LLM:            {"title": "Meeting Lisa", "date": "2026-04-28T10:00", "notes": "..."}
Action Layer:   Benachrichtigung geplant

Sub-Features / abhängige Issues

  • Intent-Router Classifier (ONNX, on-device)
  • PII-Guard NER-Modell (ONNX, on-device)
  • sqlite-vec Integration + Embedding-Pipeline
  • MLC-LLM Integration (aus #113)
  • E2E-Verschlüsselung für Server-Sync
  • Feedback-Loop: Nutzerverhalten als Trainings-Signal
  • Persönliche Wissensbasis UI (Einträge einsehen / löschen)

Abhängigkeiten

  • ONNX Runtime (#79) — bereits integriert
  • IMAP-Client (Epic #101) — erste Datenquelle
  • On-Device KI für Mails (#113) — erster konkreter Use-Case dieser Architektur
## Vision Die App wird langfristig zu einem **persönlichen, lernenden Assistenten** ausgebaut. Da dabei hochsensible Daten (Mails, Termine, Notizen, Verhalten) verarbeitet werden, gilt: - Verarbeitung findet **ausschließlich on-device** statt - Server speichert **nur E2E-verschlüsselte Blobs** — kein Klartextzugriff - Schlüssel verlassen das Gerät nie - Kein Drittanbieter-KI-SDK mit Telemetrie (kein Google AI Edge, kein OpenAI) --- ## Architektur: Mehrstufige Pipeline Kein Monolith-LLM für alles — stattdessen spezialisierte Schichten: ``` Input (Text, Mail, Sprache, Foto) ↓ [1] PII-Guard — sensible Daten markieren, nie roh raussenden ↓ [2] Intent-Router — schneller ML-Classifier (Was will der User?) ↓ [3] Extraktoren — spezialisierte ONNX-Modelle pro Domain ↓ [4] RAG-Lookup — persönliche Wissensbasis abrufen ↓ [5] LLM-Orchestrator — lokales LLM mit persönlichem Kontext ↓ [6] Action Layer — Task / Termin / Erinnerung / Antwort erzeugen ↓ [Sync Layer] — E2E-verschlüsselt auf Server ``` --- ## Schichten im Detail | Schicht | Aufgabe | Technologie | Latenz | |---------|---------|-------------|--------| | PII-Guard | Namen, IBAN, Adressen erkennen & maskieren | NER (ONNX) | <30ms | | Intent-Router | Kategorie des Inputs bestimmen | DistilBERT-tiny (ONNX) | <50ms | | Extraktoren | Datum, Personen, Orte, Mengen extrahieren | Fine-tuned NER (ONNX) | <100ms | | RAG-Lookup | Relevante persönliche Einträge abrufen | sqlite-vec + MiniLM-Embeddings | <100ms | | LLM-Orchestrator | Reasoning, Antworten, Entscheidungen | Phi-3 Mini / Gemma 2B (MLC-LLM) | 1–3s | Die Modelle kommunizieren nicht direkt — jedes gibt strukturiertes JSON aus, das die nächste Schicht als Input bekommt. --- ## Persönliches Lernen via RAG (kein LLM-Fine-Tuning) LLMs on-device zu fine-tunen ist zu rechenintensiv. Stattdessen **RAG + Feedback-Loop**: ### Persönliche Wissensbasis (lokal, verschlüsselt) - Alle Mails, Tasks, Termine, Notizen als Embeddings gespeichert - Embedding-Modell: `all-MiniLM-L6-v2` → ONNX (~23 MB) - Vector Store: `sqlite-vec` (SQLite-Extension, kein Server nötig) ### Feedback-Signale - User akzeptiert / lehnt Vorschlag ab → gewichteter Eintrag im Vector Store - Kleine Klassifikatoren (Intent, Extraktion) können on-device mit Nutzerfeedback nachtrainiert werden ### Ergebnis Das LLM „kennt" den User durch Kontext im Prompt — nicht durch veränderte Gewichte. --- ## E2E-Verschlüsselung ``` Device Server ├── Rohdaten (Klartext) ├── nur verschlüsselte Blobs ├── Verarbeitung (Klartext) ├── kein Inhaltszugriff ├── Schlüssel (bleiben lokal) └── reiner Sync/Backup-Store └── AES-256-GCM Verschlüsselung ↓ → Upload ``` - Schlüsselableitung: Argon2 aus PIN/Biometrie - Geräteübergreifende Sync: Schlüsselübertragung per QR-Code oder Passphrase - Server-Schema: nur `user_id`, `blob_id`, `encrypted_data`, `updated_at` --- ## Beispielablauf **User sagt:** „Erinnere mich morgen an das Meeting mit Lisa" ``` Intent-Router: {"intent": "reminder"} Extraktor: {"person": "Lisa", "time": "tomorrow", "type": "meeting"} RAG-Lookup: [letzte 3 Meetings mit Lisa als Kontext] LLM: {"title": "Meeting Lisa", "date": "2026-04-28T10:00", "notes": "..."} Action Layer: Benachrichtigung geplant ``` --- ## Sub-Features / abhängige Issues - [ ] Intent-Router Classifier (ONNX, on-device) - [ ] PII-Guard NER-Modell (ONNX, on-device) - [ ] sqlite-vec Integration + Embedding-Pipeline - [ ] MLC-LLM Integration (aus #113) - [ ] E2E-Verschlüsselung für Server-Sync - [ ] Feedback-Loop: Nutzerverhalten als Trainings-Signal - [ ] Persönliche Wissensbasis UI (Einträge einsehen / löschen) --- ## Abhängigkeiten - ONNX Runtime (#79) — bereits integriert - IMAP-Client (Epic #101) — erste Datenquelle - On-Device KI für Mails (#113) — erster konkreter Use-Case dieser Architektur
admin-mrrm commented 2026-04-27 00:39:15 +02:00
Author
Owner
Copy link

Ergänzung: Zwei-Gang-Verarbeitung (Echtzeit + Nacht-Batch)

Motivation

Komplexere Auswertungen (Foto-Analyse, Embedding-Aufbau, Klassifikator-Nachtraining) sind zu rechenintensiv für Echtzeit. Lösung: deferred processing — Ausführung nachts, wenn das Gerät lädt und idle ist.

Zwei-Gang-Architektur

Modus Trigger Modell Qualität Latenz
Echtzeit User-Aktion Phi-3 Mini / Gemma 2B gut 1–3s
Nacht-Batch Laden + Screen off Llama 3.1 8B GGUF besser egal

Nacht-Tasks (Beispiele)

  • Fotos analysieren (Szenen, Personen, OCR auf Dokumenten)
  • Embeddings für neue Mails/Notizen berechnen → Wissensbasis aktualisieren
  • Kleine Klassifikatoren mit gesammeltem Nutzerfeedback nachtrainieren
  • Tages-/Wochenrückblick generieren
  • E-Mail-Batch-Zusammenfassungen erstellen

Architektur-Ergänzung: Job Queue mit Prioritätsstufen

Job Queue
  ├── immediate  → bestehende Echtzeit-Pipeline (Phi-3 Mini / Gemma 2B)
  └── deferred   → Nacht-Batch-Pipeline
        ├── größeres Modell laden (Llama 3.1 8B GGUF via MLC-LLM)
        ├── Jobs abarbeiten (Fotos, Embeddings, Nachtraining)
        └── Ergebnisse in lokale Wissensbasis schreiben

Technische Umsetzung (Android)

WorkManager mit Charging + Idle Constraints — genau dafür gebaut:

val constraints = Constraints.Builder()
    .setRequiresCharging(true)
    .setRequiresDeviceIdle(true)
    .build()

val nightWork = PeriodicWorkRequestBuilder<NightProcessingWorker>(1, TimeUnit.DAYS)
    .setConstraints(constraints)
    .build()

WorkManager.getInstance(context).enqueueUniquePeriodicWork(
    "night-processing",
    ExistingPeriodicWorkPolicy.KEEP,
    nightWork
)

In Expo: natives Android-Modul das WorkManager wrапpt (expo-background-fetch reicht für einfache Tasks, für schwere Workloads besser eigenes Modul).

Sub-Feature

  • Job Queue implementieren (immediate / deferred Priorität)
  • WorkManager Native Module für Expo
  • Nacht-Batch-Worker: Foto-Analyse, Embedding-Update, Klassifikator-Nachtraining
  • Größeres GGUF-Modell (Llama 3.1 8B) für Nacht-Modus laden/entladen
## Ergänzung: Zwei-Gang-Verarbeitung (Echtzeit + Nacht-Batch) ### Motivation Komplexere Auswertungen (Foto-Analyse, Embedding-Aufbau, Klassifikator-Nachtraining) sind zu rechenintensiv für Echtzeit. Lösung: **deferred processing** — Ausführung nachts, wenn das Gerät lädt und idle ist. --- ### Zwei-Gang-Architektur | Modus | Trigger | Modell | Qualität | Latenz | |-------|---------|--------|----------|--------| | **Echtzeit** | User-Aktion | Phi-3 Mini / Gemma 2B | gut | 1–3s | | **Nacht-Batch** | Laden + Screen off | Llama 3.1 8B GGUF | besser | egal | --- ### Nacht-Tasks (Beispiele) - Fotos analysieren (Szenen, Personen, OCR auf Dokumenten) - Embeddings für neue Mails/Notizen berechnen → Wissensbasis aktualisieren - Kleine Klassifikatoren mit gesammeltem Nutzerfeedback nachtrainieren - Tages-/Wochenrückblick generieren - E-Mail-Batch-Zusammenfassungen erstellen --- ### Architektur-Ergänzung: Job Queue mit Prioritätsstufen ``` Job Queue ├── immediate → bestehende Echtzeit-Pipeline (Phi-3 Mini / Gemma 2B) └── deferred → Nacht-Batch-Pipeline ├── größeres Modell laden (Llama 3.1 8B GGUF via MLC-LLM) ├── Jobs abarbeiten (Fotos, Embeddings, Nachtraining) └── Ergebnisse in lokale Wissensbasis schreiben ``` --- ### Technische Umsetzung (Android) **WorkManager** mit Charging + Idle Constraints — genau dafür gebaut: ```kotlin val constraints = Constraints.Builder() .setRequiresCharging(true) .setRequiresDeviceIdle(true) .build() val nightWork = PeriodicWorkRequestBuilder<NightProcessingWorker>(1, TimeUnit.DAYS) .setConstraints(constraints) .build() WorkManager.getInstance(context).enqueueUniquePeriodicWork( "night-processing", ExistingPeriodicWorkPolicy.KEEP, nightWork ) ``` In Expo: natives Android-Modul das WorkManager wrапpt (expo-background-fetch reicht für einfache Tasks, für schwere Workloads besser eigenes Modul). --- ### Sub-Feature - [ ] Job Queue implementieren (immediate / deferred Priorität) - [ ] WorkManager Native Module für Expo - [ ] Nacht-Batch-Worker: Foto-Analyse, Embedding-Update, Klassifikator-Nachtraining - [ ] Größeres GGUF-Modell (Llama 3.1 8B) für Nacht-Modus laden/entladen
admin-mrrm commented 2026-04-27 06:53:32 +02:00
Author
Owner
Copy link

Integration in die bestehende App

Analyse der bestehenden Infrastruktur

Der Stack (Expo 54, NestJS, PostgreSQL/Drizzle, ONNX-Pipeline in Vorbereitung) ist gut geeignet. Kein Big-Bang-Umbau nötig — die Architektur wächst inkrementell.

Was direkt passt

ONNX-Modelle (ML-Schichten)
Infrastruktur ist vorbereitet — #79 (ONNX Runtime in EAS Build) ist der einzige Blocker. Sobald das steht, laufen PII-Guard, Intent-Router und Extraktoren direkt in apps/mobile.

Vector Store (RAG-Wissensbasis)
expo-sqlite ist bereits im Stack. sqlite-vec ist eine SQLite-Extension — lässt sich als Expo-Plugin einbinden. Passt in die bestehende lokale Datenhaltung.

E2E-Verschlüsselung
expo-secure-store ist bereits integriert (Schlüsselspeicherung). Encryption-Layer on top der Sync-Logik + neues NestJS-Modul für verschlüsselte Blobs → überschaubar.

Pluggable Feature Pattern
Das bestehende packages/feature-*-Muster ist genau richtig:

  • packages/ai-engine — Abstraktion für alle KI-Operationen (ONNX, LLM, Embeddings)
  • packages/feature-ai-assistant — UI-Komponenten für KI-Vorschläge

Was neue Infrastruktur braucht

Komponente Aufwand Wo
MLC-LLM neues Expo Native Module apps/mobile
WorkManager (Nacht-Batch) neues Expo Native Module apps/mobile
Job Queue Backend BullMQ oder pg-boss apps/api
OCR-Service erweitern OCR-Service → allgemeiner ML-Service apps/ocr → apps/ml

Natürlicher Evolutionspfad

Jetzt:    ONNX (#79) fertigstellen
            → ML-Schichten (PII-Guard, Intent-Router, Extraktoren)

Danach:   sqlite-vec + Embedding-Modell
            → Persönliche Wissensbasis (RAG)

Dann:     MLC-LLM Native Module
            → LLM-Orchestrator on-device

Später:   WorkManager + Job Queue
            → Nacht-Batch-Verarbeitung

Voraussetzungen: ONNX (#79) und IMAP-Client (Epic #101) sind die natürlichen ersten Schritte — alles andere baut darauf auf.

## Integration in die bestehende App ### Analyse der bestehenden Infrastruktur Der Stack (Expo 54, NestJS, PostgreSQL/Drizzle, ONNX-Pipeline in Vorbereitung) ist gut geeignet. Kein Big-Bang-Umbau nötig — die Architektur wächst inkrementell. --- ### Was direkt passt **ONNX-Modelle (ML-Schichten)** Infrastruktur ist vorbereitet — #79 (ONNX Runtime in EAS Build) ist der einzige Blocker. Sobald das steht, laufen PII-Guard, Intent-Router und Extraktoren direkt in `apps/mobile`. **Vector Store (RAG-Wissensbasis)** `expo-sqlite` ist bereits im Stack. `sqlite-vec` ist eine SQLite-Extension — lässt sich als Expo-Plugin einbinden. Passt in die bestehende lokale Datenhaltung. **E2E-Verschlüsselung** `expo-secure-store` ist bereits integriert (Schlüsselspeicherung). Encryption-Layer on top der Sync-Logik + neues NestJS-Modul für verschlüsselte Blobs → überschaubar. **Pluggable Feature Pattern** Das bestehende `packages/feature-*`-Muster ist genau richtig: - `packages/ai-engine` — Abstraktion für alle KI-Operationen (ONNX, LLM, Embeddings) - `packages/feature-ai-assistant` — UI-Komponenten für KI-Vorschläge --- ### Was neue Infrastruktur braucht | Komponente | Aufwand | Wo | |------------|---------|-----| | MLC-LLM | neues Expo Native Module | `apps/mobile` | | WorkManager (Nacht-Batch) | neues Expo Native Module | `apps/mobile` | | Job Queue Backend | BullMQ oder pg-boss | `apps/api` | | OCR-Service erweitern | OCR-Service → allgemeiner ML-Service | `apps/ocr` → `apps/ml` | --- ### Natürlicher Evolutionspfad ``` Jetzt: ONNX (#79) fertigstellen → ML-Schichten (PII-Guard, Intent-Router, Extraktoren) Danach: sqlite-vec + Embedding-Modell → Persönliche Wissensbasis (RAG) Dann: MLC-LLM Native Module → LLM-Orchestrator on-device Später: WorkManager + Job Queue → Nacht-Batch-Verarbeitung ``` **Voraussetzungen:** ONNX (#79) und IMAP-Client (Epic #101) sind die natürlichen ersten Schritte — alles andere baut darauf auf.
pm-bot commented 2026-06-06 16:19:03 +02:00
Collaborator
Copy link

Audit 2026-06-06 — Epic-Stand + Realitäts-Check

Das Epic ist 6 Wochen alt und wird jetzt im Rahmen einer Portfolio-Priorisierung von type/idea zu type/feature + prio/medium gehoben. Bevor wir in Implementierung gehen, ein Stand-Check gegen den ursprünglichen Body — einige Annahmen haben sich durch zwischenzeitliche Entscheidungen verschoben.

Veraltete Annahmen im Body

  1. „ONNX Runtime (#79) — bereits integriert" — nicht mehr zutreffend. Im OCR-Pivot zu Google ML Kit (v0.6.0, #423/#424) wurde TrOCR/ONNX als Stack verworfen (IAM-Korpus-Bias). onnxruntime-react-native ist nicht mehr im aktiven Mobile-Stack. Damit ist die im Epic-Body zentrale ONNX-basierte 6-Stufen-Pipeline (PII-Guard, Intent-Router, Extraktoren als ONNX) ohne Tech-Stack.

  2. „IMAP-Client (Epic #101) — erste Datenquelle" — IMAP-Reader + NLI-Kategorisierung + Paperless-Archiv laufen, aber: GF-Entscheidung 2026-06-06 hat Mail auf prio/low gesetzt (siehe #109/#110-Kommentare + Memory project_mail_strategy.md). KI-on-Mail (#113) wartet explizit auf diese KI-Foundation hier — die Reihenfolge ist jetzt #122 zuerst, dann #113, nicht parallel.

  3. „On-Device KI für Mails (#113) — erster konkreter Use-Case" — bleibt richtig, aber #113 ist explizit Folge-Epic, nicht parallel.

  4. MLC-LLM, sqlite-vec, MiniLM-Embedding-Pipeline — keines davon ist im Repo. Alle Phasen, die das voraussetzen, sind heute Greenfield.

Was implizit fehlt

  • PII-Guard-Modell-Quelle offen (welches NER, deutsches Vokabular?)
  • iOS-Support für LLM-on-Device unklar (MLC-LLM hat iOS-Support, aber 1-3s Latenz auf Mid-Range-iPhone?)
  • APK-Größe + Modellverteilung-Strategie — Phi-3 Mini ~2 GB quantisiert ist sportlich für Mobile-Download
  • E2E-Krypto-Implementierung — Argon2 + AES-256-GCM auf React Native (welche Lib, Performance auf älteren Phones?)
  • Feedback-Loop für Klassifikator-Nachtraining — wer trainiert wann, mit welchem Compute?

Was bleibt valide

  • Vision: persönlicher, lernender Assistent, Privacy-First, On-Device, RAG statt Fine-Tuning ist konzeptionell solide.
  • Mehrstufige Pipeline-Idee (PII-Guard → Intent → Extraktor → RAG → LLM) ist Stand-der-Kunst und sinnvoll.
  • Zwei-Gang-Verarbeitung (Kommentar 1 von admin-mrrm) macht Sinn, aber abhängig vom Tech-Stack.

Nächste PM-Schritte

  1. arch-question (folgt) — Tech-Stack-Update (ONNX-Ersatz), LLM-Distribution, sqlite-vec auf Expo, Embedding-Modell, Phasen-Aufteilung, iOS-Story.
  2. Body-Update nach Arch-Antwort — die veralteten Stack-Annahmen ersetzen.
  3. Sub-Issues eröffnen — erst nach Klärung der Architektur, sonst werden sie sofort obsolet wie die ursprünglichen 7 Bullet-Points.
  4. Phasen-Reihenfolge: klar definieren, was Foundation ist (Embeddings + RAG?) und was späteres aufbauen kann.

Label-Update auf type/feature + prio/medium erfolgt zeitgleich mit diesem Audit.

## Audit 2026-06-06 — Epic-Stand + Realitäts-Check Das Epic ist 6 Wochen alt und wird jetzt im Rahmen einer Portfolio-Priorisierung von `type/idea` zu `type/feature` + `prio/medium` gehoben. Bevor wir in Implementierung gehen, ein Stand-Check gegen den ursprünglichen Body — einige Annahmen haben sich durch zwischenzeitliche Entscheidungen verschoben. ### Veraltete Annahmen im Body 1. **„ONNX Runtime (#79) — bereits integriert"** — nicht mehr zutreffend. Im OCR-Pivot zu Google ML Kit (v0.6.0, #423/#424) wurde TrOCR/ONNX als Stack verworfen (IAM-Korpus-Bias). `onnxruntime-react-native` ist nicht mehr im aktiven Mobile-Stack. Damit ist die im Epic-Body zentrale ONNX-basierte 6-Stufen-Pipeline (PII-Guard, Intent-Router, Extraktoren als ONNX) **ohne Tech-Stack**. 2. **„IMAP-Client (Epic #101) — erste Datenquelle"** — IMAP-Reader + NLI-Kategorisierung + Paperless-Archiv laufen, aber: GF-Entscheidung 2026-06-06 hat Mail auf `prio/low` gesetzt (siehe #109/#110-Kommentare + Memory `project_mail_strategy.md`). KI-on-Mail (#113) wartet explizit auf diese KI-Foundation hier — die Reihenfolge ist jetzt **#122 zuerst, dann #113**, nicht parallel. 3. **„On-Device KI für Mails (#113) — erster konkreter Use-Case"** — bleibt richtig, aber #113 ist explizit Folge-Epic, nicht parallel. 4. **`MLC-LLM`, `sqlite-vec`, `MiniLM`-Embedding-Pipeline** — keines davon ist im Repo. Alle Phasen, die das voraussetzen, sind heute Greenfield. ### Was implizit fehlt - **PII-Guard-Modell-Quelle** offen (welches NER, deutsches Vokabular?) - **iOS-Support für LLM-on-Device** unklar (MLC-LLM hat iOS-Support, aber 1-3s Latenz auf Mid-Range-iPhone?) - **APK-Größe + Modellverteilung-Strategie** — Phi-3 Mini ~2 GB quantisiert ist sportlich für Mobile-Download - **E2E-Krypto-Implementierung** — Argon2 + AES-256-GCM auf React Native (welche Lib, Performance auf älteren Phones?) - **Feedback-Loop für Klassifikator-Nachtraining** — wer trainiert wann, mit welchem Compute? ### Was bleibt valide - Vision: persönlicher, lernender Assistent, Privacy-First, On-Device, RAG statt Fine-Tuning ist konzeptionell solide. - Mehrstufige Pipeline-Idee (PII-Guard → Intent → Extraktor → RAG → LLM) ist Stand-der-Kunst und sinnvoll. - Zwei-Gang-Verarbeitung (Kommentar 1 von admin-mrrm) macht Sinn, aber abhängig vom Tech-Stack. ### Nächste PM-Schritte 1. **arch-question (folgt)** — Tech-Stack-Update (ONNX-Ersatz), LLM-Distribution, sqlite-vec auf Expo, Embedding-Modell, Phasen-Aufteilung, iOS-Story. 2. **Body-Update nach Arch-Antwort** — die veralteten Stack-Annahmen ersetzen. 3. **Sub-Issues eröffnen** — erst nach Klärung der Architektur, sonst werden sie sofort obsolet wie die ursprünglichen 7 Bullet-Points. 4. **Phasen-Reihenfolge:** klar definieren, was Foundation ist (Embeddings + RAG?) und was späteres aufbauen kann. Label-Update auf `type/feature` + `prio/medium` erfolgt zeitgleich mit diesem Audit.
pm-bot commented 2026-06-06 16:19:21 +02:00
Collaborator
Copy link

Arch-Question ist eröffnet: #438 — wartet auf @arch-bot. Sub-Issues folgen nach Antwort.

Arch-Question ist eröffnet: #438 — wartet auf @arch-bot. Sub-Issues folgen nach Antwort.
pm-bot commented 2026-06-06 16:26:37 +02:00
Collaborator
Copy link

Produkt-Entscheidung (Decision Record 2026-06-06)

Nach Architekt-Antwort in #438 die folgenden Entscheidungen für die KI-Assistent-Foundation. Beziehe mich auf die dort begründeten Empfehlungen.

Entscheidung 1 — ML-Stack für kleine Pipeline-Schichten: ONNX wieder rein ✅

onnxruntime-react-native für PII-Guard, Intent-Router, Extraktoren-NER. Zwei Inferenz-Engines parallel (ML Kit für OCR, ONNX für KI) ist bewusster Tradeoff — verschiedene Use-Cases, verschiedene Privacy-Anforderungen. Google ML Kit Custom Models verworfen für sensible Daten.

Konkret: xlm-roberta-base-german-ner (Q8, ~110 MB) für PII/NER, DistilBERT-Tiny für Intent-Router (~25 MB Q8).

Entscheidung 2 — LLM-Runtime: llama.cpp via llama.rn ✅

Phi-3-Mini-4K-Instruct Q4_K_M (~2.3 GB) als Default-Modell. Download-on-First-Run, nicht Bundle (App-Store-Limit). MLC-LLM verworfen wegen TVM-Compilation-Overhead. iOS-Erst-Release zurückgestellt bis Phase-2-Performance-Validation.

Entscheidung 3 — RAG-Stack: sqlite-vec + multilingual-e5-small ✅

sqlite-vec via Custom EAS Build mit Config-Plugin (managed Workflow bleibt). Embedding-Modell multilingual-e5-small (~118 MB Q8) — für deutsche User notwendige Multilingual-Foundation, ggü reinem englischen MiniLM. Inkrementelle Re-Indexierung on-the-fly (~15-30 ms), Initial-Indexing als Background-Job.

Entscheidung 4 — E2E-Sync: Out-of-scope für Foundation, eigenes Epic später ✅

Foundation läuft lokal-only auf Hauptgerät. E2E-Sync wird separates Sub-Epic „[Epic] KI-Assistent — E2E-Sync" mit libsodium-Basis (react-native-sodium). Body-Skizze (AES-256-GCM + Argon2 + QR-Pairing) bleibt langfristiges Ziel.

Entscheidung 5 — Phasen-Reihenfolge (8 Phasen) ✅

Geänderte Reihenfolge ggü ursprünglichem PM-Vorschlag: LLM-Spike vorgezogen auf Phase 2, um Performance-Risiko früh zu validieren.

Phase Inhalt User-Wert
1 Embeddings + sqlite-vec + Indexierung semantische Suche in App
2 Single-Call-LLM-Spike („Mail zusammenfassen") LLM-Validation auf realen Geräten
3 PII-Guard NER interner Sicherheitslayer
4 Intent-Router + Extraktoren + RAG-im-LLM-Prompt volle Pipeline
5 Action Layer (Tasks/Termine erzeugen) sichtbarer Use-Case
6 Feedback-Loop (Vector-Store-Gewichtung) Lerneffekt
7 Erste echte Use-Cases — #113 KI-on-Mail strategisch
8 E2E-Sync (eigenes Epic) Multi-Device

Übernommene Folge-Effekte aus #438

  1. Web-KI als separates Sub-Epic — Mobile zuerst (Phasen 1-5), Web-Variante danach mit web-llm (WebGPU + Wasm).
  2. Battery/Thermal-UX: LLM-Pipeline-Aufrufe Default „bei Ladung" oder „bei Wifi", User-Opt-In-Override.
  3. Modell-Update-Channel: API-Endpoint GET /models/manifest, App vergleicht installierte Versionen — eigenes Sub-Issue im API-Bereich.
  4. Privacy-Audit-Trail-UI: Indikator pro Verarbeitungs-Schritt sichtbar machen („PII-Guard hat 3 Namen maskiert, lokal").
  5. LLM-Download-Fallback: graceful degradation oder Feature-Toggle aus — nie silent fail.
  6. DataSource-Interface in Phase 1 vorwegnehmen (IDataSource mit extractChunks()/getIndexKey()/subscribeToUpdates()) — damit Day-Planner/Wissensbasis/Urlaub später ohne Pipeline-Umbau plugbar sind.
  7. Test-Strategie: Golden-Set + Semantic-Similarity-Assertions statt String-Equality für LLM-Outputs.

Sub-Issues — Phase 1 zuerst eröffnen

Ich eröffne im nächsten Schritt zunächst nur die Phase-1-Sub-Issues (klare Foundation, geringes Risiko). Spätere Phasen folgen nach Phase-1-Abschluss und ggf. Phase-2-Spike-Ergebnis.

  • P1.1 Embedding-Modell-Integration (multilingual-e5-small als ONNX, on-device-Inferenz)
  • P1.2 sqlite-vec via EAS Build Config-Plugin + DB-Schema
  • P1.3 IDataSource-Interface + Adapter für vorhandene Quellen (Mails, Shopping-Lists, Notes)
  • P1.4 Background-Job für Initial-Indexing + inkrementelle Re-Indexierung
  • P1.5 Semantische Suche UI (Mobile, Web folgt)

#438 schließe ich als beantwortet.

Strategischer Hinweis

#113 (KI-on-Mail) wartet explizit auf Phase 5+. Mail-Stack-Pivot (GF-Entscheidung in #109/#110) und KI-Foundation-Push hier sind komplementär — Mail wird nicht von außen wachsen, sondern durch diese KI-Schicht.

## Produkt-Entscheidung (Decision Record 2026-06-06) Nach Architekt-Antwort in #438 die folgenden Entscheidungen für die KI-Assistent-Foundation. Beziehe mich auf die dort begründeten Empfehlungen. ### Entscheidung 1 — ML-Stack für kleine Pipeline-Schichten: **ONNX wieder rein** ✅ `onnxruntime-react-native` für PII-Guard, Intent-Router, Extraktoren-NER. Zwei Inferenz-Engines parallel (ML Kit für OCR, ONNX für KI) ist bewusster Tradeoff — verschiedene Use-Cases, verschiedene Privacy-Anforderungen. Google ML Kit Custom Models verworfen für sensible Daten. Konkret: `xlm-roberta-base-german-ner` (Q8, ~110 MB) für PII/NER, DistilBERT-Tiny für Intent-Router (~25 MB Q8). ### Entscheidung 2 — LLM-Runtime: **llama.cpp via `llama.rn`** ✅ Phi-3-Mini-4K-Instruct Q4_K_M (~2.3 GB) als Default-Modell. **Download-on-First-Run**, nicht Bundle (App-Store-Limit). MLC-LLM verworfen wegen TVM-Compilation-Overhead. iOS-Erst-Release zurückgestellt bis Phase-2-Performance-Validation. ### Entscheidung 3 — RAG-Stack: **sqlite-vec + multilingual-e5-small** ✅ sqlite-vec via Custom EAS Build mit Config-Plugin (managed Workflow bleibt). Embedding-Modell `multilingual-e5-small` (~118 MB Q8) — für deutsche User notwendige Multilingual-Foundation, ggü reinem englischen MiniLM. Inkrementelle Re-Indexierung on-the-fly (~15-30 ms), Initial-Indexing als Background-Job. ### Entscheidung 4 — E2E-Sync: **Out-of-scope für Foundation, eigenes Epic später** ✅ Foundation läuft lokal-only auf Hauptgerät. E2E-Sync wird separates Sub-Epic „[Epic] KI-Assistent — E2E-Sync" mit libsodium-Basis (`react-native-sodium`). Body-Skizze (AES-256-GCM + Argon2 + QR-Pairing) bleibt langfristiges Ziel. ### Entscheidung 5 — Phasen-Reihenfolge (8 Phasen) ✅ Geänderte Reihenfolge ggü ursprünglichem PM-Vorschlag: **LLM-Spike vorgezogen** auf Phase 2, um Performance-Risiko früh zu validieren. | Phase | Inhalt | User-Wert | |---|---|---| | **1** | Embeddings + sqlite-vec + Indexierung | semantische Suche in App | | **2** | Single-Call-LLM-Spike („Mail zusammenfassen") | LLM-Validation auf realen Geräten | | **3** | PII-Guard NER | interner Sicherheitslayer | | **4** | Intent-Router + Extraktoren + RAG-im-LLM-Prompt | volle Pipeline | | **5** | Action Layer (Tasks/Termine erzeugen) | sichtbarer Use-Case | | **6** | Feedback-Loop (Vector-Store-Gewichtung) | Lerneffekt | | **7** | Erste echte Use-Cases — #113 KI-on-Mail | strategisch | | **8** | E2E-Sync (eigenes Epic) | Multi-Device | ### Übernommene Folge-Effekte aus #438 1. **Web-KI als separates Sub-Epic** — Mobile zuerst (Phasen 1-5), Web-Variante danach mit `web-llm` (WebGPU + Wasm). 2. **Battery/Thermal-UX:** LLM-Pipeline-Aufrufe Default „bei Ladung" oder „bei Wifi", User-Opt-In-Override. 3. **Modell-Update-Channel:** API-Endpoint `GET /models/manifest`, App vergleicht installierte Versionen — eigenes Sub-Issue im API-Bereich. 4. **Privacy-Audit-Trail-UI:** Indikator pro Verarbeitungs-Schritt sichtbar machen („PII-Guard hat 3 Namen maskiert, lokal"). 5. **LLM-Download-Fallback:** graceful degradation oder Feature-Toggle aus — nie silent fail. 6. **DataSource-Interface in Phase 1 vorwegnehmen** (`IDataSource` mit `extractChunks()`/`getIndexKey()`/`subscribeToUpdates()`) — damit Day-Planner/Wissensbasis/Urlaub später ohne Pipeline-Umbau plugbar sind. 7. **Test-Strategie:** Golden-Set + Semantic-Similarity-Assertions statt String-Equality für LLM-Outputs. ### Sub-Issues — Phase 1 zuerst eröffnen Ich eröffne im nächsten Schritt zunächst nur die Phase-1-Sub-Issues (klare Foundation, geringes Risiko). Spätere Phasen folgen nach Phase-1-Abschluss und ggf. Phase-2-Spike-Ergebnis. - [ ] **P1.1** Embedding-Modell-Integration (`multilingual-e5-small` als ONNX, on-device-Inferenz) - [ ] **P1.2** sqlite-vec via EAS Build Config-Plugin + DB-Schema - [ ] **P1.3** `IDataSource`-Interface + Adapter für vorhandene Quellen (Mails, Shopping-Lists, Notes) - [ ] **P1.4** Background-Job für Initial-Indexing + inkrementelle Re-Indexierung - [ ] **P1.5** Semantische Suche UI (Mobile, Web folgt) #438 schließe ich als beantwortet. ### Strategischer Hinweis #113 (KI-on-Mail) wartet explizit auf Phase 5+. Mail-Stack-Pivot (GF-Entscheidung in #109/#110) und KI-Foundation-Push hier sind komplementär — Mail wird nicht von außen wachsen, sondern durch diese KI-Schicht.
pm-bot commented 2026-06-06 16:29:07 +02:00
Collaborator
Copy link

Phase-1-Sub-Issues eröffnet 2026-06-06

  • #439 — P1.1 Embedding-Modell multilingual-e5-small on-device
  • #440 — P1.2 sqlite-vec via EAS Build + DB-Schema
  • #441 — P1.3 IDataSource-Interface + Adapter (Mail/Liste/Notiz)
  • #442 — P1.4 Background-Job für Initial-Indexing + inkrementelle Re-Indexierung
  • #443 — P1.5 Semantische Suche UI (Mobile)

Abhängigkeiten: P1.1 + P1.2 sind parallel umsetzbar. P1.3 ist unabhängig. P1.4 braucht 1+2+3. P1.5 braucht 1+2+4. → empfohlene Reihenfolge: (1, 2, 3 parallel) → 4 → 5.

## Phase-1-Sub-Issues eröffnet 2026-06-06 - #439 — P1.1 Embedding-Modell `multilingual-e5-small` on-device - #440 — P1.2 sqlite-vec via EAS Build + DB-Schema - #441 — P1.3 `IDataSource`-Interface + Adapter (Mail/Liste/Notiz) - #442 — P1.4 Background-Job für Initial-Indexing + inkrementelle Re-Indexierung - #443 — P1.5 Semantische Suche UI (Mobile) Abhängigkeiten: P1.1 + P1.2 sind parallel umsetzbar. P1.3 ist unabhängig. P1.4 braucht 1+2+3. P1.5 braucht 1+2+4. → empfohlene Reihenfolge: (1, 2, 3 parallel) → 4 → 5.
pm-bot commented 2026-06-06 16:37:22 +02:00
Collaborator
Copy link

Korrektur 2026-06-06 — Stack-Reality-Check nachgeholt

Der Audit-Kommentar oben sowie das Decision Record waren auf falscher Basis: Repo-Code wurde nicht ge-grept, nur OCR-Pivot-Memory befragt. Stand korrekt:

Was tatsächlich produktiv läuft

  • onnxruntime-react-native — voll integriert via NLI-Classifier (apps/mobile/src/services/nli-classifier.ts)
  • llama.rn — produktiv mit Llama 3.2 3B Q4_K_M (~2 GB Download-on-First-Run) für Mail-Kategorisierung
  • @huggingface/transformers — Tokenization
  • Custom Expo Plugin with-onnxruntime-package
  • Hermes-Polyfills
  • ModelManager mit komplettem Lifecycle (Download → Init → Inferenz → Progress-Events)
  • NLI-Model Xenova/mDeBERTa-v3-base-xnli-multilingual-nli-2mil7 (~280 MB Q8) live
  • Rejection-Store + Debug-Logging

Die KI-Foundation ist also deutlich weiter als der Audit angenommen hat. Mail-Kategorisierung (#251 ff., Mai 2026) hat das produktiv etabliert — der OCR-Pivot zu ML Kit betrifft nur den OCR-Stack, nicht den Mail-/KI-Stack.

Auswirkungen auf die Decisions

  • Decision 1 (ONNX wieder rein): redundant — ONNX läuft. Korrekte Formulierung: „bestehenden ONNX-Pfad für KI-Pipeline-Schichten weiternutzen". xlm-roberta-base-german-ner als ONNX-Modell hinzulegen ist additiv, kein Stack-Wechsel.
  • Decision 2 (LLM-Runtime llama.cpp via llama.rn): stimmt, aber Llama 3.2 3B ist das produktive Modell (nicht Phi-3 Mini wie im Decision-Record beschrieben). Tradeoff: 3B braucht Pixel 8 Pro / 12 GB RAM-Klasse — entsprechende Erwartungshaltung beim Phase-2-LLM-Spike.
  • Decision 3 (RAG-Stack sqlite-vec + multilingual-e5-small): unverändert valide — sqlite-vec fehlt wirklich noch.
  • Decision 4 (E2E-Sync später): unverändert.
  • Decision 5 (Phasen-Reihenfolge): unverändert — alle Phasen-1-Items fehlen wirklich, Foundation für RAG/Embeddings/Suche/DataSource ist neu.

Auswirkungen auf die Sub-Issues

  • #439 (P1.1 Embedding-Modell): Scope deutlich kleiner als beschrieben — kein „ONNX-Reintegration", sondern Embedding-Modell zum bestehenden ONNX-Stack dazustellen (analog zu wie NLI-Classifier das macht). Update am Sub-Issue folgt.
  • #440–#443: Scope und Akzeptanzkriterien bleiben unverändert.

Was nicht passiert ist

Das Decision Record (Kommentar 2991) bleibt im Ticket-Verlauf stehen — damit ist nachvollziehbar, was wann auf welcher Annahme entschieden wurde. Diese Korrektur ist additiv.

Lerneffekt

Memory-Eintrag feedback_refresh_repo_code.md ergänzt — Repo-Code-Grep gehört vor jeden Stack-Audit, nicht nur git/Gitea-State.

## Korrektur 2026-06-06 — Stack-Reality-Check nachgeholt Der Audit-Kommentar oben sowie das Decision Record waren auf falscher Basis: Repo-Code wurde nicht ge-grept, nur OCR-Pivot-Memory befragt. Stand korrekt: ### Was tatsächlich produktiv läuft - `onnxruntime-react-native` — voll integriert via NLI-Classifier (`apps/mobile/src/services/nli-classifier.ts`) - `llama.rn` — produktiv mit **Llama 3.2 3B Q4_K_M** (~2 GB Download-on-First-Run) für Mail-Kategorisierung - `@huggingface/transformers` — Tokenization - Custom Expo Plugin `with-onnxruntime-package` - Hermes-Polyfills - ModelManager mit komplettem Lifecycle (Download → Init → Inferenz → Progress-Events) - NLI-Model `Xenova/mDeBERTa-v3-base-xnli-multilingual-nli-2mil7` (~280 MB Q8) live - Rejection-Store + Debug-Logging Die KI-Foundation ist also **deutlich weiter** als der Audit angenommen hat. Mail-Kategorisierung (#251 ff., Mai 2026) hat das produktiv etabliert — der OCR-Pivot zu ML Kit betrifft nur den OCR-Stack, nicht den Mail-/KI-Stack. ### Auswirkungen auf die Decisions - **Decision 1 (ONNX wieder rein):** redundant — ONNX läuft. Korrekte Formulierung: „bestehenden ONNX-Pfad für KI-Pipeline-Schichten weiternutzen". `xlm-roberta-base-german-ner` als ONNX-Modell hinzulegen ist additiv, kein Stack-Wechsel. - **Decision 2 (LLM-Runtime llama.cpp via llama.rn):** stimmt, aber **Llama 3.2 3B** ist das produktive Modell (nicht Phi-3 Mini wie im Decision-Record beschrieben). Tradeoff: 3B braucht Pixel 8 Pro / 12 GB RAM-Klasse — entsprechende Erwartungshaltung beim Phase-2-LLM-Spike. - **Decision 3 (RAG-Stack sqlite-vec + multilingual-e5-small):** unverändert valide — sqlite-vec fehlt wirklich noch. - **Decision 4 (E2E-Sync später):** unverändert. - **Decision 5 (Phasen-Reihenfolge):** unverändert — alle Phasen-1-Items fehlen wirklich, Foundation für RAG/Embeddings/Suche/DataSource ist neu. ### Auswirkungen auf die Sub-Issues - **#439 (P1.1 Embedding-Modell):** Scope deutlich kleiner als beschrieben — kein „ONNX-Reintegration", sondern Embedding-Modell zum bestehenden ONNX-Stack dazustellen (analog zu wie NLI-Classifier das macht). Update am Sub-Issue folgt. - **#440–#443:** Scope und Akzeptanzkriterien bleiben unverändert. ### Was nicht passiert ist Das Decision Record (Kommentar 2991) bleibt im Ticket-Verlauf stehen — damit ist nachvollziehbar, was wann auf welcher Annahme entschieden wurde. Diese Korrektur ist additiv. ### Lerneffekt Memory-Eintrag `feedback_refresh_repo_code.md` ergänzt — Repo-Code-Grep gehört vor jeden Stack-Audit, nicht nur git/Gitea-State.
pm-bot commented 2026-06-06 17:51:44 +02:00
Collaborator
Copy link

Phase-1-Wireup als PR eröffnet 2026-06-06

PR #444 integriert die fünf Sub-Issues (#439–#443) auf dem Branch wireup/ai-foundation-phase1 und verdrahtet den nativen Stack (op-sqlite + onnxruntime + IndexingService) hinter der Suche-Route.

  • Statisch grün: tsc clean, vitest 177/177
  • Vor Merge nach main Pflicht: Physical-Device-Pass nach apps/mobile/docs/ai-foundation-verification.md (Build mit expo prebuild --clean, sqlite-vec-Smoke, ONNX-Load, End-to-End-Search)

Sobald der Device-Pass durch ist und Drone grün ist, kann PR #444 gemerged werden — damit landet Phase 1 der KI-Foundation in main.

## Phase-1-Wireup als PR eröffnet 2026-06-06 PR **#444** integriert die fünf Sub-Issues (#439–#443) auf dem Branch `wireup/ai-foundation-phase1` und verdrahtet den nativen Stack (op-sqlite + onnxruntime + IndexingService) hinter der Suche-Route. - Statisch grün: tsc clean, vitest 177/177 - Vor Merge nach `main` Pflicht: **Physical-Device-Pass** nach `apps/mobile/docs/ai-foundation-verification.md` (Build mit `expo prebuild --clean`, sqlite-vec-Smoke, ONNX-Load, End-to-End-Search) Sobald der Device-Pass durch ist und Drone grün ist, kann PR #444 gemerged werden — damit landet Phase 1 der KI-Foundation in `main`.
pm-bot commented 2026-06-08 22:45:21 +02:00
Collaborator
Copy link

Phase 1 Code-Complete + Live auf main (2026-06-08)

PR #444 wurde durch PR #445 ersetzt (Branch-Konsolidierung nach RC2-RC17-Schleife) und am 2026-06-08 in main gemerged. Alle Phase-1-Sub-Issues sind closed:

  • #439 P1.1 Embedding-Modell multilingual-e5-small on-device (closed 2026-06-06)
  • #440 P1.2 sqlite-vec via EAS-Build + DB-Schema (closed 2026-06-06)
  • #441 P1.3 IDataSource-Adapter Mail/Listen/Notizen (closed 2026-06-06)
  • #442 P1.4 Background-Job Initial + inkrementelles Re-Indexing (closed 2026-06-06)
  • #443 P1.5 Semantische Suche UI Mobile (closed 2026-06-06)
  • #85 Mutation-Observer in api-client-context.tsx (closed via PR #445)

Release-Stream

17 Release-Candidates (v0.6.6-rc1–rc17) zum Bring-up auf echter Hardware (Hermes-Quirks bei PreTrainedTokenizer, ONNX-Tensor-Shapes, sqlite-vec EAS-Build).

Phase-2 Wireup (Mutation-Observer)

PR #445 enthält bereits 5 deterministische Unit-Tests, die useCreateList/Update/Delete -> onSourceChange gegen ein gemocktes ApiClient verifizieren — die fragile Maestro-E2E-Validierung wurde durch diese Sperre ersetzt.

Heute Mo 2026-06-08

  • rc18 (v0.6.6-rc18) gebaut mit Mutation-Observer-Tests + Diagnostik-Cleanup
  • X-Dev-User-Bypass in JwtAuthGuard wurde zuerst NODE_ENV-gegated eingefuehrt (#446 PR Iteration 1) und dann auf ein eigenes ALLOW_DEV_USER_HEADER-Env-Var entkoppelt (PR #446 + server-stack #23), weil dev-neu bewusst NODE_ENV=production faehrt. Bypass jetzt aktiv auf dev.api.mrrm.de, prod-alt unberuehrt.

Was noch aussteht (= Voraussetzung fuer Phase-1-Block-Closure)

  • Device-Validation rc18 auf rpi5 — phase2-mutation-observer-smoke Maestro-Flow gegen rc18-APK. Build #1017 publish-debug-apk laeuft gerade.
  • Bei gruenem Maestro-Lauf: roadmap.json rc18 status next -> done.

Was Phase 2+ angeht

Dieses Epic bleibt offen. Phase 2 (Multi-Source-Indexing aktiv beim User-Workflow, Re-Index bei Mail-Eingang etc.) und folgende Phasen (PII-Guard, Intent-Router, RAG-Lookup, lokales LLM) sind in der ursprünglichen Architektur-Skizze beschrieben und werden als eigene Sub-Issues angelegt sobald die Phase-1-Device-Validation durch ist.

## Phase 1 Code-Complete + Live auf `main` (2026-06-08) PR #444 wurde durch **PR #445** ersetzt (Branch-Konsolidierung nach RC2-RC17-Schleife) und am 2026-06-08 in `main` gemerged. Alle Phase-1-Sub-Issues sind closed: - #439 P1.1 Embedding-Modell `multilingual-e5-small` on-device (closed 2026-06-06) - #440 P1.2 sqlite-vec via EAS-Build + DB-Schema (closed 2026-06-06) - #441 P1.3 `IDataSource`-Adapter Mail/Listen/Notizen (closed 2026-06-06) - #442 P1.4 Background-Job Initial + inkrementelles Re-Indexing (closed 2026-06-06) - #443 P1.5 Semantische Suche UI Mobile (closed 2026-06-06) - #85 Mutation-Observer in `api-client-context.tsx` (closed via PR #445) ### Release-Stream 17 Release-Candidates (`v0.6.6-rc1`–`rc17`) zum Bring-up auf echter Hardware (Hermes-Quirks bei PreTrainedTokenizer, ONNX-Tensor-Shapes, sqlite-vec EAS-Build). ### Phase-2 Wireup (Mutation-Observer) PR #445 enthält bereits 5 deterministische Unit-Tests, die `useCreateList/Update/Delete -> onSourceChange` gegen ein gemocktes ApiClient verifizieren — die fragile Maestro-E2E-Validierung wurde durch diese Sperre ersetzt. ### Heute Mo 2026-06-08 - **rc18** (`v0.6.6-rc18`) gebaut mit Mutation-Observer-Tests + Diagnostik-Cleanup - **X-Dev-User-Bypass** in JwtAuthGuard wurde zuerst NODE_ENV-gegated eingefuehrt (#446 PR Iteration 1) und dann auf ein eigenes `ALLOW_DEV_USER_HEADER`-Env-Var entkoppelt (PR #446 + server-stack #23), weil dev-neu bewusst `NODE_ENV=production` faehrt. Bypass jetzt aktiv auf `dev.api.mrrm.de`, prod-alt unberuehrt. ### Was noch aussteht (= Voraussetzung fuer Phase-1-Block-Closure) - **Device-Validation rc18 auf rpi5** — `phase2-mutation-observer-smoke` Maestro-Flow gegen rc18-APK. Build #1017 publish-debug-apk laeuft gerade. - Bei gruenem Maestro-Lauf: `roadmap.json` rc18 status `next` -> `done`. ### Was Phase 2+ angeht Dieses Epic bleibt offen. Phase 2 (Multi-Source-Indexing aktiv beim User-Workflow, Re-Index bei Mail-Eingang etc.) und folgende Phasen (PII-Guard, Intent-Router, RAG-Lookup, lokales LLM) sind in der ursprünglichen Architektur-Skizze beschrieben und werden als eigene Sub-Issues angelegt sobald die Phase-1-Device-Validation durch ist.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
chore/roadmap-rc32-done
feat/rc32-fdroid-nightly
feat/rc31-auto-index-on-mutation
feat/rc30-auto-index
chore/roadmap-rc28-done
feat/360-projects-source
chore/roadmap-rc27-done
feat/habits-ui
chore/roadmap-rc26-done
feat/planner-v1-depends-on
chore/roadmap-rc25-done
feat/calendar-settings-ui
chore/roadmap-rc24-done
feat/candidate-mark-done
chore/roadmap-rc23-done
fix/shared-schema-todo
chore/roadmap-rc22-done
chore/release-rc22
feat/todo-candidate-writer
chore/roadmap-rc21-done
chore/roadmap-rc21-json-fix
chore/release-v0.6.6-rc21
feat/day-planner-empty-state-ctas
chore/roadmap-rc17-rc18-done
chore/phase2-smoke-manual-trigger
chore/roadmap-rc19-done
fix/list-screens-scrollable
feat/dev-user-header-env-gate
wireup/ai-foundation-phase1
feat/443-search-ui
feat/442-background-indexer
feat/441-data-source-interface
feat/440-sqlite-vec
feat/439-embedding-service
feat/425-mlkit-image-preview-integration
archive/spike-77-ocr-mobile
fix/gitea-release-shell-scope
feat/396-version-sync
feat/376-e2e-drone-integration
feat/374-e2e-playwright-setup
feat/372-planner-v1
feat/370-calendar-read
feat/368-planner-v0
feat/366-habit-source
feat/178-mail-candidate-writer
feat/253-nli-template-ab
fix/348-settings-nav-hijack-v2
fix/347-web-side-drawer
fix/349-profile-menu-close
feat-297-sender-memory-ui
feat-296-web-classifier-sender-memory
feat/294-sender-label-memory
chore/268-analyze-script-dynamic-labels
fix/268-nli-threshold-025
fix/266-imap-getmessage-timeout
fix-imap-unhandled-error
fix-175-onnxruntime-anchor
fix-175-onnxruntime-mainapp
ci-release-gate-apk
ci-mobile-bundle-check
fix-175-native-startup
fix-175-stub-onnxruntime-web
fix-175-import-meta-hermes
feat-web-parcel-scan-toggle
feat-tracking-manual-sync
fix-track17-carrier-ids
feat-232-mail-scanner
feat-233-trackings-post
feat-aftership-provider
feat-195-loading-skeletons
feat-197-error-boundary
feat-194-toast-system
chore/add-claude-md
155-auth-callback-route
feat/fdroid-deploy
fix/mail-messages-pagination-types
feat/ocr-correction-review
fix/ocr-inference-oom
fix/ocr-oom-and-finetune-training
feat/ocr-easyocr-and-training-data
feat/ocr-image-rotate-preview
feat/mobile-image-picker-57
feat/ocr-parse-image-endpoint
feat/lists-notes-e2e
fix/web-show-auth-error-body
fix/deploy-envfile
fix/deploy-ssh-port
feat/drone-deploy
fix/drone-secret-names
fix/dockerfile-deploy-flag
feat/drone-ci
feat/apps-web
feat/shopping-list-crud
v0.6.7-rc33
v0.6.6-rc32
v0.6.6-rc31
v0.6.6-rc30
v0.6.6-rc29
v0.6.6-rc28
v0.6.6-rc27
v0.6.6-rc26
v0.6.6-rc25
v0.6.6-rc24
v0.6.6-rc23
v0.6.6-rc22
v0.6.6-rc21
v0.6.6-rc20
v0.6.6-rc19
debug-rpi5
v0.6.6-rc18
v0.6.6-rc17
v0.6.6-rc16
v0.6.6-rc15
v0.6.6-rc14
v0.6.6-rc13
v0.6.6-rc12
v0.6.6-rc11
v0.6.6-rc10
v0.6.6-rc9
v0.6.6-rc8
v0.6.6-rc7
v0.6.6-rc6
v0.6.6-rc5
v0.6.6-rc4
v0.6.6-rc3
v0.6.6-rc2
v0.6.6-rc1
v0.6.5
v0.6.4
v0.6.3
v0.6.2
v0.6.1
v0.6.0
v0.5.0
v0.4.6
v0.4.5
v1.0.515
v1.0.468
v1.0.449
v1.0.442
Labels
Clear labels   
app/archiv

Document & email archive (Paperless-ngx integration)

  
app/einkaufslisten

   
app/imap-client

   
app/wissensbasis

   
arch-answered

arch-question wurde vom Architekten beantwortet und vom PM in Produkt-Entscheidung übersetzt

  
arch-question

Anfrage an Software-Architekt — Tech-/Architektur-Entscheidung gebraucht (PM hat sie nicht selbst getroffen)

  
area/api

NestJS backend

  
area/auth

Keycloak / OIDC

  
area/infra

Monorepo / CI / tooling

  
area/mobile

Expo React Native app

  
area/shared

Shared packages

  
area/ui

Tamagui UI package

  
area/web

Vite web app

  
portfolio-status

Wöchentlicher CEO-Portfolio-Status

  
prio/high

High priority

  
prio/low

Low priority

  
prio/medium

Medium priority

  
roadmap/public

In der public Roadmap der App sichtbar (roadmap.json kuratiert)

  
size/l

2-3 days

  
size/m

About 1 day

  
size/s

Half a day

  
size/xl

More than 3 days — should be split

  
size/xs

Less than 1 hour

  
status/blocked

Waiting on something

  
status/needs-info

Open questions before work can continue

  
type/bug

Something is broken

  
type/chore

Infra / tooling / maintenance

  
type/docs

Documentation

  
type/feature

New user-facing functionality

  
type/idea

   
type/refactor

Code refactor without behavior change

No labels
app/archiv
app/einkaufslisten
app/imap-client
app/wissensbasis
arch-answered
arch-question
area/api
area/auth
area/infra
area/mobile
area/shared
area/ui
area/web
portfolio-status
prio/high
prio/low
prio/medium
roadmap/public
size/l
size/m
size/s
size/xl
size/xs
status/blocked
status/needs-info
type/bug
type/chore
type/docs
type/feature
type/idea
type/refactor
Milestone
Clear milestone
No items
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
admin-mrrm/mrrmlabapp#122
No description provided.