• v0.6.6-rc12 0709229a17

    v0.6.6-rc12
    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-07 15:22:57 +02:00 | 117 commits to main since this release

    rc11-Tag-Build failte im lint-Step: 'clearHfLocalPaths' war in embedding-service.ts importiert aber nur im Test verwendet. rc12 entfernt den unused Import — identischer Code-Path wie rc11, einziger Unterschied ist die saubere Import-Liste.

    Highlights

    • fix(embedding): unused 'clearHfLocalPaths'-Import in embedding-service.ts entfernt — wird ausschließlich im Spec verwendet. Sonst keine Code-Änderung gegenüber rc11.
    Downloads
  • v0.6.6-rc10 8ddc339ceb

    v0.6.6-rc10
    Some checks failed
    continuous-integration/drone/push Build is failing
    continuous-integration/drone/tag Build is passing
    Stable

    admin-mrrm released this 2026-06-07 14:46:24 +02:00 | 120 commits to main since this release

    rc9 lieferte die Tokenizer-Files erfolgreich auf Disk (User-Agent-Header genügte offenbar dem HF-CDN), aber AutoTokenizer.from_pretrained hängt wieder genau wie in rc6 — diesmal mit installiertem Fetch-Interceptor. Wahrscheinlichste Erklärung: transformers.js holt vor den /resolve/main/-Dateien noch andere HF-URLs (z.B. /api/models//tree/main für Revision-Lookup), die NICHT auf HF_BASE matchen → Interceptor lässt durch → Original-Fetch hängt erneut auf Hermes. rc10 erweitert den Interceptor auf ALLE huggingface.co-URLs (unbekannte → synthetisches 404) und emittiert pro Fetch-Aufruf einen Status mit URL-Pfad. Das macht sichtbar welche URLs transformers.js anfragt und ob der Interceptor überhaupt getriggert wird.

    Highlights

    • feat(embedding): Interceptor fängt jetzt jede huggingface.co-URL (#122). Bekannte /resolve/main/ → Disk-Read; alles andere → 404. Verhindert dass nicht-erfasste HF-API-Calls den nativen fetch hängen lassen.
    • feat(embedding): Pro Fetch-Aufruf wird 'loading-tokenizer' mit filename='fetch#N ' re-emittiert. Debug-Bar zeigt jetzt 'embedder: loading tokenizer · fetch#3 api/models/intfloat/multilingual-e5-small/tree/main' — der Hang ist einer konkreten URL zuzuordnen.
    • Tests bleiben grün (18/18); Interceptor-Verhalten für non-HF-URLs (passthrough) unverändert.
    Downloads
  • v0.6.6-rc9 5060112365

    v0.6.6-rc9
    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-07 14:17:33 +02:00 | 122 commits to main since this release

    rc8 zeigte auf dem Gerät 'embedder: downloading tokenizer files' und hängt da — also auch der native expo-Downloader klemmt für die kleinen JSON-Files, obwohl er die 120 MB ONNX-Datei einwandfrei geladen hat. Bevor wir die Lösung wählen (Bundling als Asset vs. eigener Mirror vs. andere CDN) brauchen wir einen klaren Diagnosesignal: welche Datei genau hängt und ob überhaupt Bytes fließen. rc9 emittiert pro-Datei Progress mit Dateinamen + Bytes und timeoutet jede Datei nach 45s — wir sehen jetzt 'downloading tokenizer tokenizer.json 0.0 / 17.4 MB' bzw. 'error: tokenizer-download timeout (45s): tokenizer.json'.

    Highlights

    • feat(embedding): pro-Datei 'downloading-tokenizer' Status mit filename + bytesWritten/bytesTotal (#122). Debug-Bar rendert 'embedder: downloading tokenizer X.X / Y.Y MB' — Hang ist jetzt einer konkreten Datei zuzuordnen.
    • feat(embedding): Per-File-Timeout (45s) via Promise.race um downloadAsync — kein indefinites Hängen mehr, klare Error-Message mit Dateiname.
    • feat(embedding): User-Agent-Header 'mrrmlab/0.6.6 expo-file-system' im Download-Request — Falsifiziert die Hypothese 'HF blockt anonyme Requests'.
    • EmbeddingProgress um optionales 'filename'-Feld erweitert; bestehende Tests bleiben grün.
    Downloads
  • v0.6.6-rc8 1600bcca8f

    v0.6.6-rc8
    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-07 13:51:53 +02:00 | 124 commits to main since this release

    rc7 lieferte den entscheidenden Hinweis (via dem neuen Maestro-Flow): der Probe-fetch zu huggingface.co hängt selbst — Hermes' JS-fetch klemmt komplett gegen HF. Dieselbe Domain funktioniert hingegen über expo-file-system's nativen Downloader (createDownloadResumable hat den 120 MB ONNX-File bereits einwandfrei geladen). rc8 zieht die Konsequenz: alle vier Tokenizer-Dateien (tokenizer.json, tokenizer_config.json, special_tokens_map.json, config.json) werden jetzt ebenfalls per nativem Downloader auf Disk geholt, und ein fetch-Interceptor leitet alle HF-URLs in transformers.js auf lokale Disk-Reads um. Der JS-fetch sieht huggingface.co nie wieder.

    Highlights

    • feat(embedding): ensureModelFilesDownloaded lädt 4 Tokenizer-JSONs zusätzlich zum ONNX-Model via createDownloadResumable (#122). Neue Sub-Status 'downloading-tokenizer' wird in der Debug-Bar als 'embedder: downloading tokenizer files' angezeigt.
    • feat(embedding): globalThis.fetch-Monkey-Patch in initialize() — alle Requests an huggingface.co/intfloat/multilingual-e5-small/* werden über FileSystem.readAsStringAsync aus dem lokalen Cache bedient. AutoTokenizer.from_pretrained ruft transparent gegen Disk, kein Network-Hang mehr möglich. Non-HF-URLs gehen unverändert durch.
    • Test-getrieben: rc7-Probe-Tests entfernt (Mechanismus aufgegeben), 5 neue Tests (Tokenizer-Download-Liste, downloading-tokenizer-Status, Interceptor-Disk-Read, Query-String-Stripping, Passthrough für Non-HF).
    Downloads
  • v0.6.6-rc7 761034195b

    v0.6.6-rc7
    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-07 12:41:04 +02:00 | 126 commits to main since this release

    rc6 (via dem neuen Maestro-Flow phase1-indexing-smoke) hat eindeutig gezeigt: der Embedder hängt bei 'loading tokenizer' — also genau inside AutoTokenizer.from_pretrained() von transformers.js. ONNX-Download + Datei-auf-Disk sind ok, InferenceSession.create wird nie erreicht. Da der Hang innerhalb der HF-Lib silent ist (kein Error, kein Progress) braucht es einen direkten Probe-Schritt davor: rc7 fetched tokenizer_config.json selbst per fetch() und emittiert das als eigene Sub-Status 'loading-tokenizer-probe'. Probe-Erfolg bedeutet: Netzwerk + HF-Endpoint sind ok, der Hang liegt in transformers.js Internals. Probe-Fehler liefert sofort HTTP-Status statt unendlich zu hängen.

    Highlights

    • feat(embedding): neue Sub-Status 'loading-tokenizer-probe' vor AutoTokenizer.from_pretrained (#122). Direkter fetch() auf https://huggingface.co/intfloat/multilingual-e5-small/resolve/main/tokenizer_config.json — Erfolg → next status 'loading-tokenizer'; Fehler → throw mit HTTP-Status statt Lib-Hang.
    • Debug-Bar rendert jetzt 'embedder: probing tokenizer endpoint' bzw. 'embedder: loading tokenizer' — auf dem Phone unterscheidet sich Netz-Hang von transformers.js-Hang.
    • Test-getrieben: 3 neue embedding-service.spec Tests (probe-call vor from_pretrained, probe-Status-Emit-Order, Probe-Fehler-Pfad mit HTTP-Status im error-Event).
    Downloads
  • v0.6.6-rc6 7cd934d914

    v0.6.6-rc6
    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-07 11:54:22 +02:00 | 128 commits to main since this release

    rc5 zeigte am Phone 'embedder: loading' und blieb dort hängen. 'loading' fasste bisher zwei sequenzielle Schritte zusammen: AutoTokenizer.from_pretrained (HF-Tokenizer-Download via transformers.js) und InferenceSession.create (ONNX-Parse). rc6 splittet das in 'loading-tokenizer' / 'loading-session' damit der Bottleneck auf dem Gerät sichtbar wird. Parallel: erster echter Maestro-E2E-Flow (phase1-indexing-smoke), den scripts/maestro-pi.sh auf dem rpi5+Phone fährt — er drückt den Debug-Button und wartet bis 'embedder: ready' erscheint (timeout 3min). Damit kann jeder zukünftige RC autonom verifiziert werden.

    Highlights

    • feat(embedding): EmbeddingStatus split 'loading' → 'loading-tokenizer' + 'loading-session' (#122). Debug-Bar rendert jetzt 'embedder: loading tokenizer' bzw. 'loading session' — entlarvt welcher der zwei Schritte auf dem Gerät hängt (Tokenizer-Fetch von HF vs. ONNX-Compile).
    • feat(e2e): phase1-indexing-smoke.yaml — neuer Maestro-Flow der den Debug-Index-Button drückt und auf 'embedder: ready' wartet. Läuft via scripts/maestro-pi.sh, kein clearState (cached ONNX bleibt auf disk → 30s statt 3min auf Re-Runs). Erlaubt autonome Fix-Verifikation ohne menschliche Lesung.
    • Test-getrieben: 1 neuer embedding-service.spec Test prüft loading-tokenizer → loading-session → ready Reihenfolge.
    Downloads
  • v0.6.6-rc5 b6cc6f7d88

    v0.6.6-rc5
    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-07 08:07:34 +02:00 | 130 commits to main since this release

    Folge-RC zu rc4: rc4 zeigte am Phone 'embedder: idle' nach Druck auf den Debug-Button. Da idle → downloading nur durch tatsächlichen embed()-Call ausgelöst wird, ist der wahrscheinliche Grund: extractChunks gibt [] zurück (z.B. Shopping-List ohne Items vom Typ 'shopping' oder Notiz mit leerem Body), die for-Loop in IndexingService.indexSource läuft nicht, embed() wird nie aufgerufen. rc5 macht das sichtbar und ergänzt parallel die Embedder-Bytes-Anzeige für den Fall dass der Download tatsächlich klemmt.

    Highlights

    • feat(search): IndexingService emittiert 'chunks-extracted' nach jedem extractChunks-Call (#122) — auch wenn count=0. Debug-Bar zeigt 'X Quellen → Y Chunks extrahiert', damit man 0/0 (Daten leer/falscher Typ) von 'läuft noch' unterscheidet.
    • feat(search): EmbeddingProgress liefert bytesWritten + bytesTotal zusätzlich zum % (#122). Debug-Bar rendert 'downloading 23.4 / 120.0 MB' — '0.0 / 0.0 MB' (kein Content-Length) lässt sich von '0.0 / 120.0 MB' (Request akzeptiert, kein Byte) und '12.0 / 120.0 MB' (langsam) unterscheiden.
    • Test-getrieben: 1 neuer Test in indexing-service.spec für chunks-extracted (0 vs. >0), 1 neuer Test in embedding-service.spec für die Byte-Felder.
    Downloads
  • v0.6.6-rc4 9468ce3314

    v0.6.6-rc4
    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-07 01:37:45 +02:00 | 132 commits to main since this release

    Folge-RC zu rc3: nachdem rc3 auf dem Gerät 0 Chunks AND 0 Fehler meldete, hängt höchstwahrscheinlich der Embedder still beim Modell-Download (~120 MB ONNX) oder beim Laden. rc4 routet den embeddingService-Lifecycle (idle / downloading N% / loading / ready / error) durch einen neuen EmbedderStatusPort an die Debug-Bar, damit man auf dem Gerät genau sieht wo es klemmt.

    Highlights

    • feat(search): EmbedderStatusPort an SearchPorts (#122) — Debug-Bar zeigt jetzt 'embedder: downloading 47%' / 'ready' / 'error: …' und entlarvt damit silent failures, die in der Release-APK sonst unsichtbar bleiben (Hermes strippt console).
    • Lazy-Native-Boundary bleibt intakt: die Route importiert embeddingService nicht direkt, sondern bekommt nur den Port — vitest fasst onnxruntime-react-native weiterhin nie an.
    Downloads
  • v0.6.6-rc3 8cbea0b5f1

    v0.6.6-rc3
    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-06 23:22:10 +02:00 | 134 commits to main since this release

    Folge-RC zu rc2: nachdem der Debug-Indexier-Button erfolgreich Events publisht, die Suche aber leer bleibt, ergänzt rc3 in der gelben Debug-Bar einen Counter (Chunks indexed) + Fehler-Anzeige (last error). Notwendig weil Release-APKs Hermes-console.log strippen und logcat damit blind ist — ohne diese Bar gibt es keinerlei On-Device-Sichtbarkeit für Embedder- oder Vector-Store-Failures.

    Highlights

    • feat(search): Debug-Bar abonniert ports.indexing.onProgress (#122) — running totals für chunk-indexed + error events, plus letzte Fehlermeldung mit sourceType-Präfix.
    • Reine Diagnose-Iteration: keine Logik-Änderung an Embedder / IndexingService / VectorStore. Wird mit rc-Cleanup vor dem Phase-1-Final entfernt.
    Downloads
  • v0.6.6-rc2 c9dbccc69c

    v0.6.6-rc2
    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-06 19:08:48 +02:00 | 138 commits to main since this release

    Folge-RC zu rc1: ergänzt einen temporären Debug-Button auf der Suche-Route, der für alle Shopping-Listen und Notizen des Users 'created'-Events in die IndexingService-Queue feuert. Notwendig weil der api-client noch keine Mutation-Observer-Hooks publisht (kommt als Task B / Folge-PR) — ohne diesen Button bleibt der Index auf einem echten Gerät leer und das Stack-Wireup lässt sich nicht validieren.

    Highlights

    • feat(search): Debug-Index-Button (#122) — gelbe Bar oberhalb der Suche-Eingabe; ruft ports.debugIndexAll() auf und meldet, wie viele Listen/Notizen in die Queue gewandert sind.
    • search-ports erweitert um debugIndexAll() — fächert publish('created') über ShoppingListDataSource und NoteDataSource auf; Mail bleibt ausgeklammert bis #438 die sourceId-Enumeration löst.
    • Wird mit der ordentlichen Mutation-Observer-Wireup-Iteration (Task B, Folge-PR gegen #122) entfernt — bis dahin auf jedem Device-Test-Build sichtbar.
    Downloads