Validierungsprotokoll

Lokale Entwicklungs-Builds. Die Ergebnisse sind je Abschnitt datiert; ältere Artefakt-Hashes gelten nur für die zusammen mit ihnen dokumentierten Builds. Befehlsbeispiele verwenden die aktuelle Schreibweise des Projekts; historische Artefakt-Hashes beschreiben nicht die neu benannten Binärdateien. Diese Ergebnisse beschreiben tatsächlich ausgeführte Prüfungen; eine CI-Konfiguration belegt weder einen erfolgreichen entfernten CI-Lauf noch ein unabhängiges Sicherheitsaudit.

SaaS-Konten und konfigurierbare Registrierung (2026-10-14)

Release 20261014-83aca4d86199 ist auf ldny bereitgestellt. SHA-256 der Linux-Binärdatei: 83aca4d86199718587da2fe812471bffb6ea7aefd499c52ed53e6566a7dd4c73. Bereitstellung der Kontenoberfläche: 908a7085.memories-ap4.pages.dev.

• cargo fmt --all --check, cargo clippy --workspace --all-targets --locked -- -D warnings und cargo test --workspace --locked bestanden unter Windows. Bestehende optionale, umgebungsabhängige Tests behalten ihren deklarierten Status als ignoriert.
• cargo build --workspace --release --locked bestand unter Windows. Der Linux- Release-Build von memories-center bestand mit dem gesperrten Abhängigkeitsgraphen und wurde im unten beschriebenen, mit der Produktion kompatiblen Ubuntu-Container getestet.
• Center-Tests: 79 bestanden, darunter sieben Konto-/Konfigurationstests für Benutzernamenregistrierung, kanonische Identitäten, E-Mail-Verifizierung/Ablauf/Wiederverwendung, SMTP-Transportfehler, tatsächliche Zustellung an eine lokale SMTP-Testumgebung, Passwort- Hashing, begrenzten Authentifizierungsaufwand und begrenzte Anfragen, verweigerten kontenübergreifenden Lese-/Schreibzugriff, administrative Änderungen/Löschung, Abmeldung, Persistenz nach Neustart und im Fehlerfall verweigerte Schreibzugriffe von Mitgliedern.
• Node-Tests für Webclient und API-Proxy: 13 bestanden. Die Dokumentationsgenerierung prüfte lokale Links und Anker in 32 HTML-Seiten.
• Ein echter Chromium-Browser registrierte sich bei einem isolierten Center, meldete sich an und erstellte einen Erinnerungseintrag. Übergänge im E-Mail-Formular wurden mit simulierten API-Antworten geprüft; diese Browserprüfungen versandten keine E-Mails. Die E-Mail-Zustellung im Backend wurde separat über die lokale SMTP-Testumgebung geprüft, nicht über einen externen Anbieter.
• Das genaue Produktions-Image bestand einen isolierten Container-Canary-Test auf ldny mit zwei Konten, getrennten Tresoren, verweigertem kontenübergreifendem Zugriff, Abmeldung, Persistenz nach Neustart und Anmeldung bei geschlossener Registrierung. Der Canary-Container und seine synthetischen Daten wurden entfernt. Produktionsdaten wurden für diesen Test nicht verwendet.
• Der Produktionsneustart bewahrte die Tresoridentität und das Mitglieds- Token des bestehenden Eigentümers über die öffentliche Domain. Der bestehende PostgreSQL-Container und der cloudflared-Dienst liefen weiter. Eingebettete /app/-Assets und öffentliche Pages- Assets stimmen überein. Öffentliche Desktop-/Mobilseiten haben keine Fehler in der Browserkonsole und keinen horizontalen Überlauf bei 390px.
• Die Produktion wählt den E-Mail-Modus in /etc/memories-center/auth.toml. SMTP wurde am 2026-10-14 mit Tencent-Unternehmensmail und zertifikatsgeprüftem implizitem TLS auf Port 465 konfiguriert. Die Anbieterauthentifizierung bestand, der Dienst startete erfolgreich neu und die öffentliche Konfiguration meldet eine aktivierte Registrierung. Eine öffentliche Registrierungsanfrage lieferte 200 mit verification_required: true, nachdem eine Verifizierungs-E-Mail an den Anbieter übergeben worden war. Der Eingang im Postfach und die abschließende Übermittlung von Code/Passwort durch den Benutzer bleiben ungeprüft. Passwörter werden ausschließlich in geschützter Konfiguration außerhalb des Repositorys aufbewahrt.
• Geschütztes konsistentes Backup: /var/backups/memories-center/20261014-before-accounts-83aca4d86199/state-and-config.tar.gz. Nachweise, Quellcode-Patch und Build-Beleg: dist/saas-accounts-20261014/. Der Patch lässt sich auf die dokumentierte saubere Basis anwenden; Git normalisiert die Zeilenenden von Textdateien.

Gehostetes SaaS auf ldny (2026-10-14, erste Bereitstellung)

memories.ivjn.us stellt jetzt die gehostete Center-API über einen Cloudflare Worker und den bestehenden ldny-Tunnel bereit. Die statische Website, der Webclient und die unabhängige Dokumentation verbleiben auf Pages. ldny führt das Linux-Release in einem Ubuntu 24.04- Podman-Container aus, mit persistenten verschlüsselten Daten außerhalb des Images und systemd- Verwaltung für Start und Neustart.

• Öffentliches /health liefert ok; /v1/public-key identifiziert memories-saas. Anonymes /v1/session liefert 401, ein Mitglied bzw. eine Berechtigung mit passendem Geltungsbereich liefert die autorisierte Sitzung. API-Antworten verwenden Cache-Control: no-store.
• Synthetische Inhalte überstanden einen Dienstneustart. Ein echter Chromium-Browser erstellte, bearbeitete und öffnete einen Erinnerungseintrag erneut über https://memories.ivjn.us und löschte ihn anschließend. Das endgültige Container-Release bestand zwei aufeinanderfolgende systemd-Neustarts mit einem neuen persistent gespeicherten Testeintrag. Eine über die öffentliche API hoch-/heruntergeladene 1 MiB große Binärdatei stimmte im SHA-256 überein; reine Leseberechtigungen verweigerten Schreibzugriffe mit 403.
• Desktop- und Mobilbrowserprüfungen bei 390px zeigten weder horizontalen Überlauf noch Konsolen- fehler. Tokens/Inhalte waren im Browserspeicher nicht vorhanden. QA-Inhalte wurden gelöscht und temporäre Berechtigungen widerrufen. Ein bestehendes Eigentümer-Token funktionierte nach dem endgültigen Upgrade weiterhin; ein geschütztes Backup von Zustand/Konfiguration vor dem Upgrade wurde aufbewahrt.
• Alle 10 Node-Tests für die Web-API und den Edge-Proxy bestanden. Der Linux-Release-Build und lokale Linux-Smoke-Prüfungen für Authentifizierung/Persistenz/eingebettete Assets bestanden.

Dienstaufbau und Rollback sind in deploy/README.md des Repositorys beschrieben. Geheimnisse wurden auf dem Server erzeugt und außerhalb des Repositorys aufbewahrt. Diese Prüfungen belegen keine unabhängige Sicherheitszertifizierung oder öffentliche Selbstbedienungs- Kontenregistrierung. Lokale Nachweise befinden sich in dist/saas-ldny-20261014/.

Memories Web (2026-10-14, erste Frontend-Bereitstellung)

Der statische Center-Client wurde unter /app/ hinzugefügt und dieselben Assets wurden in memories-center eingebettet. Dies ist ein Client für ein gehostetes Center, kein Offline-Browsertresor. Diese erste Frontend-Bereitstellung ging dem oben dokumentierten SaaS-Rollout voraus.

• Die vollständige Rust-Prüfreihenfolge bestand: Formatprüfung, Clippy für den Workspace/alle Ziele mit Warnungen als Fehlern, Workspace-Tests mit gesperrten Abhängigkeiten und Workspace-Release-Build mit gesperrten Abhängigkeiten. Die Center-Testsuite enthält die Validierung expliziter Origins sowie CORS-Tests für Geltungsbereiche/Authentifizierung.
• node --test scripts/tests/web-client.test.mjs: 6 bestanden, mit Abdeckung der Bindung von Tokens an den Origin, Einschränkungen für Weiterleitungen/Cookies/Caches, Teilaktualisierungen, Abbruch und veralteten Antworten, fehlgeschlagenen Verbindungswettläufen, generischen Fehlern und Binärcodierung.
• Ein echter Chromium-Browser verband die statische Website auf Port 8097 mit einem temporären gehosteten Center auf Port 9297. Erstellen/Bearbeiten/erneutes Öffnen von Erinnerungseinträgen, Erstellen/Löschen von Karten sowie Datei-Upload und -Download bestanden. Ein 10,240 Byte großer Binärdownload stimmte im SHA-256 mit der Quelle überein. Leseberechtigungen deaktivierten Änderungen; eine reine Schreibberechtigung erstellte einen Erinnerungseintrag, der unabhängig mit der Eigentümerberechtigung gelesen wurde, wobei die gelöschte Karte nicht mehr vorhanden war.
• Desktop- und mobile Workspace-Layouts bei 390px wurden geprüft. Explizites Trennen löschte sichtbare Inhalte und das Token-Feld; auch die Inaktivitätssperre nach fünf Minuten wurde beobachtet. Weder localStorage noch sessionStorage enthielten Tokens oder Inhalte.
• Das Release-Center lieferte alle sieben eingebetteten Assets bytegenau entsprechend den Website-Quellen aus. Seine /app/-Seite lud ohne Fehler oder Warnungen in der Browserkonsole, und die CSP-/Sicherheitsheader wurden geprüft.

Es wurden ausschließlich synthetische Tresordaten und temporäre Berechtigungen verwendet. Diese Prüfungen belegen weder eine Verbindung zu einem Produktionstresor noch ein unabhängiges Sicherheitsaudit oder Funktionsgleichheit mit nativen Clients. Nachweise werden lokal unter dist/site-update-7647166/output/playwright/ und dist/web-client-qa/ aufbewahrt.

Aktualisierung des Website-Clients (2026-10-14)

Nacharbeiten an der Website: Download-Karten teilen nun Rasterzeilen für Hashes, primäre Schaltflächen und Metadatenlinks. Die eigenständige Dokumentation unter /docs/ enthält 29 generierte Seiten mit Navigation, Überschriftenlinks und einem auf Mobilgeräten einklappbaren Menü. python scripts/build-website-docs.py prüft lokale Links und Fragmentziele über alle 30 HTML-Seiten hinweg. node --check bestand für beide Website-Skripte. Browserprüfungen umfassten Startseite, Dokumentationsübersicht, englische und chinesische Anleitungen sowie Konfiguration bei 390px, 900px und 1440px, ohne horizontalen Seiten- überlauf oder Konsolenfehler. Download-Schaltflächen, Hashes und BUILD-INFO-Links haben übereinstimmende vertikale Positionen über die vier Desktop-Karten hinweg.

Quellcodebasis: 7647166a6d97e59e9a466fec5ead287892b428af (main, synchronisiert mit origin/main). Windows- und Linux-Pakete verwenden diesen eingecheckten Quellcode. Android enthält zusätzlich die unten beschriebene lokale R8-Korrektur zur Beibehaltung von Konstruktoren; seine BUILD-INFO.json dokumentiert source_dirty: true und den veröffentlichten Quellcode-Patch.

Die öffentlichen Basispfade sind https://r2.ivjn.us/memories/7647166/windows/, https://r2.ivjn.us/memories/7647166/linux/ und https://r2.ivjn.us/memories/7647166/android-cc5ac4b5/. Alle drei Pakete und ihre veröffentlichten Metadaten wurden erneut heruntergeladen und stimmten mit den lokalen SHA-256-Hashes überein. Der SHA-256 des Android-SOURCE.patch ist cc5ac4b57ced3bc87738d51da5ded84822627b5f05f8db024d323bde98dda4c2; git apply --check bestand gegen den sauberen Basis-Checkout.

Durchgeführte Validierung:

• Rust 1.98.0 unter Windows: cargo fmt --all --check, cargo clippy --workspace --all-targets --locked -- -D warnings, cargo test --workspace --locked und cargo build --workspace --release --locked bestanden alle. Konfigurierte ignorierte Tests bleiben ignoriert; Warnungen zur zukünftigen Kompatibilität von Abhängigkeiten bleiben bestehen.
• Windows-Paket: 47 Manifestdateien und Archiveinträge geprüft; die entpackte CLI lieferte mit --version den Wert memories 0.1.7, Relay---help bestand ebenfalls.
• Linux-Paket: mit bash scripts/package-linux.sh in einem sauberen WSL-GNU- Checkout gebaut (glibc 2.39, OpenSSL 3). Alle 45 Manifestdateien, Archiveinträge und Ausführungsberechtigungen geprüft. Die entpackte CLI bestand --version und file exec --help; ldd löste alle Abhängigkeiten auf.
• Flutter 3.44.2 / Dart 3.12.2: flutter pub get, dart format --output=none --set-exit-if-changed lib test integration_test, flutter analyze und flutter test bestanden (126 Tests).
• ARM64/x86_64-Rust-FFI-Bibliotheken neu gebaut und flutter test integration_test/native_smoke_test.dart -d emulator-5680 erfolgreich unter Android API 35 x86_64 ausgeführt. Die veraltete Zusicherung einer achtstelligen ID wurde an den Vertrag des Cores für gerade Längen von 6-16 Hexadezimalzeichen angepasst. Anschließend wurde das gewöhnliche Debug-APK neu gebaut und seine nativen Bibliotheken wurden geprüft.
• Das Release-APK wurde mit flutter build apk --release --target-platform android-arm64,android-x64 --build-number 8 gebaut, ausgerichtet und mit der in AGENTS.md dokumentierten externen Konfiguration signiert. apksigner verify bestand mit dem SHA-256 des bestehenden Release-Zertifikats d637a37d5dd77aa5753722eccf53ab1b84baed2189e603cef9c34dbf354948f8. Quell-, zusammengeführte, von Symbolen bereinigte und verpackte FFI-Bibliotheken wurden für beide ABIs geprüft.
• Die Prüfung des tatsächlich signierten Releases fand einen R8-Absturz beim Start: Room erzeugt androidx.work.impl.WorkDatabase_Impl per Reflection, doch dessen öffentlicher parameterloser Konstruktor war entfernt worden. Eine eng begrenzte Keep-Regel wurde hinzugefügt, neu gebaut und zwei Kaltstarts sowie der Einstieg in den Standalone-Modus ohne schwerwiegende AndroidRuntime-Ausnahme wurden geprüft. Der fehlgeschlagene Kandidat wurde vor der Website-Bereitstellung zurückgezogen; seine öffentliche APK-URL lieferte HTTP 404.
• Die JavaScript-Syntax der Website und lokale HTML-Ressourcen, IDs und Fragmentziele bestanden die Prüfungen. Lokale Browserprüfungen bei 1440px und 390px bestanden den zweisprachigen Wechsel ohne horizontalen Überlauf oder Konsolenfehler.

Die Produktionsbereitstellung auf Cloudflare Pages wurde unter https://09253fe4.memories-ap4.pages.dev für Projekt memories, Branch main, mit Metadaten zum veränderten Quellcode abgeschlossen. https://memories.ivjn.us/ lieferte HTTP 200 und stimmte bytegenau mit der lokalen website/index.html überein. Alle 12 Download-/Metadaten- links lieferten HTTP 200, einschließlich der beibehaltenen macOS-Links. Header für CSP, nosniff, Frame-Verweigerung, Referrer und Permissions-Policy waren vorhanden. Produktions- Browserprüfungen bestanden bei 1440px und 390px mit Wechsel zwischen Englisch und Chinesisch, ohne horizontalen Überlauf und ohne Konsolenfehler oder Warnungen. Screenshots befinden sich unter dist/site-update-7647166/output/playwright/live-*.png.

Lokale Nachweise und Hilfsprogramme befinden sich unter dist/site-update-7647166/; das Windows- Paket liegt unter dist/v0.1.7/. Signierungsgeheimnisse blieben außerhalb des Checkouts. macOS verbleibt beim bestehenden v0.1.3-Download: Der macOS-Host war offline und GitHub Actions war durch das Abrechnungs-/Ausgabenlimit des Kontos blockiert. Es wird kein neuer macOS- oder iOS-Build, keine Ausführung auf physischer ARM64-Hardware, keine Store-Veröffentlichung und kein unabhängiges Sicherheits- audit beansprucht. Die obige Linux-Validierung ersetzt für dieses Paket die Linux- Einschränkung der älteren Basisvalidierung.

Einbindung unbeaufsichtigter nativer CI-Prüfungen (2026-10-01; geplant, nicht ausgeführt)

Die Rust-Betriebssystemmatrix in .github/workflows/ci.yml plant jetzt explizite native Prüfungen nach den gewöhnlichen Workspace-Tests:

• Windows: cargo test -p memories --lib native_dpapi --locked führt die bestehenden Tests für den DPAPI-Rundlauf des aktuellen Benutzers und die Verweigerung bei veränderter Bindung aus. Sie verwenden ausschließlich synthetische Speicherpuffer, die vom nativen Pufferschutz freigegeben und mit Nullen überschrieben werden; auf den Platzhalterpfad für die Verwahrung wird nie zugegriffen.
• macOS: cargo test -p memories --lib unattended_backend::macos::tests::native_roundtrip_when_keychain_is_unlocked --locked -- --exact --ignored führt ausschließlich den ignorierten nativen Keychain-Rundlauf aus, keine anderen ignorierten Tests. Er erstellt einen synthetischen, nicht synchronisierten Eintrag mit einer eindeutigen Bindung an ein temporäres Verzeichnis und löscht dann genau diesen Eintrag, bevor das Leseergebnis geprüft oder Gleichheit zugesichert wird. Fehler bei Bereitstellung, Lesen und Bereinigung lassen den Test fehlschlagen; ein fehlgeschlagenes Erstellen löst nie die Löschung eines zuvor bestehenden Eintrags aus.

Der macOS-Runner muss einen verfügbaren, entsperrten Benutzerschlüsselbund bereitstellen, der Erstellen/Lesen/Löschen ohne Benutzeroberfläche zulässt. Es werden weder Schlüsselbundentsperrung noch Authentifizierungsoberfläche, ACL-Abschwächung, globale Schlüsselbundänderungen oder Passwortinjektion hinzugefügt. Fehlende oder gesperrte Schlüsselbunde führen zum Fehler, statt stillschweigend zu überspringen oder auf Ersatzverfahren zurückzugreifen. Schlägt die native Löschung fehl, schlägt der Test fehl und sein synthetischer Eintrag kann auf dem temporären Runner verbleiben. Frühere Formatierungs-/Lint-/Testfehler können verhindern, dass diese Schritte erreicht werden.

Diese Schritte sind für zukünftige Push-/Pull-Request-CI-Läufe konfiguriert und kein Nachweis nativer Ausführung. Es wurde kein Workflow gestartet und weder Windows- noch macOS-native Tests wurden lokal ausgeführt: Diese Implementierungsumgebung ist Linux ohne konfigurierte native Hosts. Tatsächliche native Ausführung und Validierung ohne Benutzeroberfläche bei Sperre bzw. erforderlicher Genehmigung bleiben Freigabekriterien für Releases; allein die CI-Einbindung erfüllt sie nicht.

Linux-Build- und Paketierungsskripte (2026-09-18)

Die neuen Linux-Shellskripte wurden unter Ubuntu auf WSL2 aus einem Windows-Checkout validiert. bash -n war für beide Skripte erfolgreich. Temporäre, eingecheckte Test-Repositories und simulierte Build-Werkzeuge prüften die Auswahl von Release/Debug, die explizite Auswahl des nativen Targets trotz eines widersprüchlichen CARGO_BUILD_TARGET, Pfade mit Leerzeichen, benutzerdefinierte Cargo-Target-Verzeichnisse, das Archivlayout für x86_64/aarch64, Ausführungsberechtigungen, versionierte Dokumentation/Lizenzen, Metadaten zum Quellcode-Commit und sämtliche Datei-/Archivprüfsummen. Falsches Betriebssystem, nicht unterstützte Targets, ungültige Argumente, fehlendes OpenSSL, fehlgeschlagene Builds, Arbeitskopien mit lokalen Änderungen und bereits vorhandene Paketverzeichnisse wurden wie erwartet abgewiesen; vorhandene Archive blieben unverändert.

Die WSL-Umgebung verfügt über keine Rust/C-Build-Toolchain; damit wird das Skriptverhalten mit Testartefakten geprüft, nicht die Linux-Kompilierung oder die native Laufzeit. Der aktualisierte manuelle Desktop-Workflow umfasst die Installation von Linux-Abhängigkeiten, ShellCheck, Rust-Prüfungen, Paketierung, Prüfsummenprüfung und Smoke-Test-Befehle für die entpackte CLI und den Relay; dieser Remote-Workflow wurde für diese Änderung nicht ausgeführt. Natives ARM64 sowie die Kompatibilität mit Distributionen/glibc/OpenSSL bleiben ungeprüft.

Windows v0.1.3: Abruf, eingebettete Modelle und sechsstellige IDs (2026-09-18)

Der Tag v0.1.3 und die Release-Datei BUILD-INFO.json identifizieren den Quellcode und die paketierten Dateien. Die Inferenz-Engine ist Teil der Anwendung; Modellgewichte werden separat als geprüfte Datendateien installiert und nicht von einer anderen Anwendung ausgeführt.

• Workspace-Regression: 158 bestanden, keine Fehler, 17 bewusst ignorierte Fälle, die von Hilfsprozessen/Werkzeugen/Modellen abhängen. Die abschließende Retrieval-Suite mit sechs Tests bestand ebenfalls separat, einschließlich einer neuen Regression für den Wechsel eines Dokuments von öffentlich zu privat während einer laufenden Verarbeitung, die nach Beginn des Workspace-Testlaufs hinzugefügt wurde.
• Natives EmbeddingGemma lief innerhalb des Prozesses mit tatsächlichen, festgelegten Q4-Modelldateien. Eine chinesische Frage ordnete das relevante englische Dokument über Hunde vor einem themenfremden Finanztext ein, mit endlichen, normalisierten Vektoren mit 768 Dimensionen. Ein zweiter echter CLI/Daemon-Test erstellte den Vektorindex, fand den semantischen Treffer und bestätigte die Abweisung bei Sperrung sowie das Leeren des Caches. Beide optionalen Tests bestanden, nachdem ONNX-Telemetrie vor der Sitzungserstellung ausdrücklich deaktiviert worden war.
• Die abschließende optimierte Windows-Release-CLI wurde außerdem direkt über echte Daemon-IPC geprüft: sechsstellige IDs, zwei indexierte Dokumente, der sprachübergreifende semantische Treffer und die Abweisung bei Sperrung bestanden. Ihr Bericht liegt unter target/rag-release-smoke.json; es wurde keine externe Embedding-Anwendung verwendet.
• Die Modellinstallation über die tatsächliche Release-CLI bestand gegen einen temporären Loopback-Mirror: Ein eingeschleuster HTTP-429-Fehler und eine unterbrochene Modellantwort wurden durch Wiederholungen/Bereichsanforderungen aufgefangen (59 Anfragen, 53 Bereiche), und alle sieben Modelldateien entsprachen ihren festgelegten SHA-256-Prüfsummen. Eine erneute Installation bei gestopptem Mirror verwendete die geprüften Dateien offline wieder. Die Installation initialisierte keinen verschlüsselten Speicher.
• HTTP-Testumgebungen prüfen Gemini-/kompatible Nutzdaten, angeforderte Dimensionen, Prüfungen von Reihenfolge/Anzahl/Dimension der Embeddings, gelerntes Reranking, die Ablehnung von Zitaten, Wiederholungen bei vorübergehenden Fehlern, Authentifizierungsfehler ohne Wiederholung, Abbruch und tatsächliches HTTPS-Proxy-CONNECT. Antwortinhalte bei Fehlern und direkte Wiedergaben von API-Schlüsseln werden unterdrückt.
• Search/RAG-Regressionen decken chinesische Begriffe, any/all/phrase-Modi, Unicode-Chunk-Offsets, Wiederverwendung/Invalidierung des Vektor-Caches, verborgene Zugangsdaten/private/gelöschte Inhalte, Sperrung und Berechtigungswiderruf, tresorübergreifende Abweisung, die Ablehnung der Remote-Offenlegung bei ausschließlich gerätegebundener Freigabe sowie Dokumentänderungen während der Modellverarbeitung ab. CLI- und MCP-Ingestion/Retrieval funktionieren im BM25-Modus ohne Modell.
• Sechsstellige IDs, die Erweiterung von sechs auf acht Zeichen bei Kollisionen, die Kompatibilität mit alten achtstelligen Eingaben und typisierte Referenzprojektionen bestehen zusammen mit den bisherigen Regressionen für Autorisierung/Speicherung/FFI. Kanonische gespeicherte IDs und Sicherheitsfingerabdrücke bleiben unverändert.
• Formatierung, Clippy für den Workspace/alle Ziele mit -D warnings, optimierte Builds und ein Core-Build ohne die optionale native Embedding-Funktion bestehen. Vorhandene Hinweise zur zukünftigen Kompatibilität von Abhängigkeiten und informative Warnungen des nativen Linkers bleiben bestehen.
• Live-Dienste von Kunden für Gemini/Generierung/Reranking wurden nicht aufgerufen; die Protokollprüfung verwendet synthetische HTTP-Testumgebungen. macOS-/Linux-Laufzeit und native mobile Builds wurden hier nicht geprüft. Die mobile FFI stellt lexikalisches Retrieval bereit, weist aber modellgestützte Operationen ab. Die Flutter-Oberfläche wurde nicht geändert.

Modellrevision: 5090578d9565bb06545b4552f76e6bc2c93e4a66 aus onnx-community/embeddinggemma-300m-ONNX. Protokolle liegen unter target/rag-*.log, Download-/Mirror-Aufzeichnungen unter target/. Es wurden ausschließlich synthetische Speicher, Dokumente und Zugangsdaten verwendet.

Windows v0.1.2: Desktop-Status und Konfiguration (2026-09-18)

Der Tag v0.1.2 identifiziert diesen Quellcode. Die Release-Datei BUILD-INFO.json verknüpft den exakten Commit mit jeder paketierten Datei; SHA256SUMS umfasst außerdem die separate Beispielkonfiguration. Das Windows-Archiv enthält die Tray-Anwendung, die eingebettete WebUI, sämtliche versionierte Dokumentation, das TOML-Beispiel und die Lizenzen der mitgelieferten Schriftarten.

• cargo test --workspace --locked -- --test-threads=2: 144 bestanden, keine Fehler, 14 bewusst ignorierte Fälle für Subprozess-Hilfsprogramme/externe Werkzeuge. Eine verstärkte Regression für Konfigurationsweitergabe/Live-WebUI bestand außerdem separat gegen den abschließenden Quellcode (zwei Desktop-Integrationstests).
• Formatierung, Clippy für den Workspace/alle Ziele mit -D warnings und optimierte Workspace-Builds bestanden mit Rust 1.98.1 MSVC. Vorhandene Hinweise zur zukünftigen Kompatibilität von Abhängigkeiten und informative FFI-Linker-Warnungen bleiben bestehen.
• Regressionen decken die Abweisung anhand von Capability/Host/Origin/fetch-site, das Fehlen von Änderungs- oder generischen IPC-Routen, Token-Rotation, Herunterfahren bei unvollständigen HTTP-Verbindungen, passiven Ablauf bei Inaktivität, verborgene Details im gesperrten Zustand und MCP-Abweisung ab. Die echte Daemon-/WebUI-Integration deckt Einrichtung, Zähler im entsperrten Zustand, Sperrung und Trennung ab.
• Konfigurationstests decken die Rangfolge CLI/Umgebung/Datei, relative Speicherpfade, Inspektion ohne Speicher, explizite Konfigurationsweitergabe an Prüfprozesse, die gespeicherte Sprache im gewählten Home-Verzeichnis, Relay-Standardwerte, fehlerhafte Werte, bereinigte Fehlermeldungen und die Erhaltung vorhandener Konfigurationsdateien ab.
• Tatsächliche Windows-Release-CLI-/Tray-Prozesse wurden mit einer temporären TOML-Datei und einem synthetischen Speicher gestartet. Der Browser prüfte gesperrte/entsperrte Zustände und drei synthetische Bibliotheken, alle fünf Sprachen sowie Desktop-/390-Pixel-Layouts ohne horizontales Überlaufen oder Browserfehler. Der Tray-Prozess blieb ohne Startfehler ansprechbar. Native Menüklicks wurden nicht geprüft, da die Automatisierungsschnittstelle kein Taskleisten-/Tray-Fenster bereitstellte.
• cargo package --list enthält die eingebetteten Assets/Schriftarten, die Konfigurationsvorlage und den Launcher-Quellcode. Syntaxprüfungen für die macOS-Shell-/Embedded-Python-Paketierung bestanden. macOS-Kompilierung, Menüleisten-Laufzeit, Signierung/Notarisierung und Linux-Laufzeitprüfungen standen auf diesem Windows-Host nicht zur Verfügung.
• Es wurden keine mobilen Assets oder Flutter-Dateien geändert; Flutter-/native Geräteläufe und die optionalen Fälle für externe Kryptografiewerkzeuge wurden für dieses Release nicht wiederholt.

Protokolle liegen unter target/desktop-config-*.log und target/config-tests.log. Der manuelle Workflow Build desktop packages stellt Windows-/macOS-Paketjobs bereit; eine Workflow-Definition belegt keinen erfolgreichen macOS-Build.

Windows v0.1.1: Dokumentation und Passwort-ID-Aliasse (2026-09-18)

Der Tag v0.1.1 identifiziert den Quellcode. Dieses ausschließlich für Windows bestimmte Vorabrelease enthält jede versionierte Datei unter docs/ mit unveränderter Verzeichnisstruktur; seine BUILD-INFO.json erfasst den Quellcode-Commit und die SHA-256-Prüfsumme jeder paketierten Datei, und SHA256SUMS umfasst das Archiv und das Build-Manifest.

• cargo test -p memories --locked --test crypto_jobs --test localization: sieben bestanden, keine Fehler; drei Tests für externe Werkzeuge wurden bewusst ignoriert. Die Regressionsabdeckung bestätigt, dass --password_id, --password und --password-id identische Pläne/Freigabe-Digests erzeugen; eine geänderte Zugangsdaten-ID verändert die Freigabe. Die Hilfe in fünf Sprachen weist auf die Aliasse hin.
• cargo fmt --all --check, Clippy für den Workspace/alle Ziele mit -D warnings und cargo build --workspace --release --locked bestanden mit Rust 1.98.1 MSVC. Vorhandene Hinweise zur zukünftigen Kompatibilität von Abhängigkeiten und FFI-Linker-Hinweise bleiben bestehen.
• Smoke-Tests für die Release-CLI-/Relay-Version und die Kryptografie-Hilfe bestanden.
• Die nachstehenden Ergebnisse für den gesamten Workspace, externe Werkzeuge und Flutter gelten für v0.1.0; diese umfassenderen Suiten wurden für dieses CLI-Alias-/Dokumentationsupdate nicht wiederholt. Es wurde kein mobiles Artefakt neu gebaut; die Flutter-Anwendungsversion bleibt unverändert.
• Der reproduzierbare Paketierungsbefehl lautet pwsh -File scripts/package-windows.ps1. Protokolle dieses Laufs liegen unter target/release-0.1.1-*.log.

Windows-v0.1.0-Vorabrelease (2026-09-18)

Lokal unter Windows x86_64 mit Rust 1.98.1 MSVC und Flutter 3.44.2 gebaut. Der Tag v0.1.0 identifiziert den Quellcode; die Release-Datei BUILD-INFO.json erfasst dessen vollständigen Commit, und SHA256SUMS umfasst die herunterladbaren Assets.

• cargo test --workspace --locked -- --test-threads=2: 131 bestanden, keine Fehler, 14 bewusst ignorierte Tests. Der Desktop war aktiv und entsperrt; beide zuvor durch die Bildschirmsperre blockierten IPC-Tests bestanden ohne Ausschlüsse.
• Die drei optionalen Kryptografie-Interoperabilitätstests bestanden separat mit synthetischen Identitäten: S/MIME, OpenPGP und Android-Signierung im APK-/AAB-Format.
• Rust-Formatierung, Clippy für den Workspace/alle Ziele mit -D warnings und cargo build --workspace --release --locked bestanden. Vorhandene Hinweise zur zukünftigen Kompatibilität von Abhängigkeiten bleiben bestehen.
• Flutter-Analyse, Dart-Formatierung und alle 36 Flutter-Tests bestanden.
• Release-CLI-Version/Kryptografie-Hilfe, Relay-Hilfe und ein echter Smoke-Test der Release-DLL (Initialisieren, Sperren, Entsperren, Alles sperren, Schließen) bestanden mit einer temporären Datenbank.
• GitHub Actions konnte nicht starten, weil GitHub eine Einschränkung aufgrund der Kontozahlung oder des Ausgabenlimits meldete. Dies sind lokale Ergebnisse, keine Ergebnisse der Remote-CI.
• Die Assets sind unsignierte Windows-Entwicklungsbinärdateien. Einrichtung/Download des Android NDK wurde nicht abgeschlossen; Android-/iOS-Artefakte und native Gerätetests wurden in diesem Lauf nicht erstellt. Linux-/macOS-Builds und die Abnahme des Produktionsrelease bleiben offen.

Protokolle liegen unter target/release-20260918-*.log.

E-Mail-Kryptografie und Anwendungssignierung (2026-09-17)

• Drei optionale Interoperabilitätstests bestehen ausschließlich mit generierten Identitäten: S/MIME-Signierung/-Verifizierung und PKCS#12-Verschlüsselung/-Entschlüsselung; getrennte OpenPGP-Signierung/-Verifizierung und Verschlüsselung/Entschlüsselung; Android-APK-Ausrichtung/-Signierung/-Verifizierung und JAR-Signierung/-Verifizierung im AAB-Format. Das APK-Testartefakt enthält ein echtes binäres Android-Manifest; der AAB-Test verwendet einen synthetischen JAR-Container und kein bereitstellbares App Bundle. Es wurden kein echtes Konto, keine echte Identität und keine echte Anwendung verwendet.
• Host-Werkzeuge: Git for Windows OpenSSL 3.5.6, MSYS GnuPG 2.4.9, Adoptium JDK 17, Android Build Tools 35.0.0 und die Android-36-Plattform-JAR. GPG-Tests verwenden --msys-gpg und temporäre Schlüsselbunde. Führen Sie die optionalen Tests mit den MEMORIES_TEST_*-Werkzeugpfaden, die in crates/cli/tests/crypto_jobs.rs genannt sind, und cargo test -p memories --locked --test crypto_jobs -- --ignored --test-threads=1 aus.
• Core-Regressionen decken lokale Rechteerhöhung, MCP-Abweisung, veränderte Freigaben, geänderte Eingaben/Werkzeuge, vorhandene Ausgaben, geheimnisfreie Audit-Daten/Ergebnisse, Bereinigung temporärer Zugangsdaten, fehlgeschlagene Werkzeugausführung und Werkzeuge ab, die erfolgreich enden, ohne eine Ausgabe zu erzeugen. CLI-Hilfe in fünf Sprachen und die Abweisung von iOS auf Nicht-macOS-Systemen werden ebenfalls getestet.
• Mit Ausnahme der beiden nachstehend genannten IPC-Fälle, die von der Bildschirmsperre abhängen, besteht der Workspace-Lauf 129 Tests, ohne Fehler und mit 14 bewusst ignorierten Tests (Subprozess-Hilfsprogramme und die drei separat ausgeführten Werkzeugtests). Der Befehl lautet cargo test --workspace --locked -- --test-threads=2 --skip actual_daemon_enforces_unlock_sudo_and_suppresses_child_secrets --skip catch_cli_stores_secrets_without_disclosure_and_requires_sudo.
• cargo build --workspace --locked, Clippy für den Workspace/alle Ziele mit -D warnings, Rust-Formatierung, Prüfung auf Whitespace-Fehler im Diff und die Prüfung der aktualisierten Skill-Datei mit quick_validate.py bestehen.
• Der vollständige Workspace-Lauf erreichte zwei bestehende Fehler bei echtem Daemon/IPC, während die Windows-Sitzung getrennt/gesperrt war (query user meldete Disc, mit LogonUI in dieser Sitzung). Der Bildschirmsperr-Hook des Daemons widerrief die synthetischen Sitzungen, was zu LOCKED-Fehlern oder Fehlern wegen entfernter Remote-Sitzungen führte. Die serielle Wiederholung dieser Tests zeigte dasselbe Sperrverhalten. Sie erfordern einen aktiven, entsperrten Desktop; der Sperrschutz wurde für die Tests nicht deaktiviert.
• iOS-Signierung ist implementiert, wurde aber zur Laufzeit unter macOS nicht geprüft. Hier ist kein Android-Gerät angeschlossen und kein NDK installiert; native mobile Bibliotheken, APKs und iOS-Artefakte wurden nicht neu gebaut. Die mobile FFI weist Desktop-Prozessjobs weiterhin ab. Eine physische Installation, die Annahme des Apple-Provisionings, PGP/MIME-Integration in E-Mail-Clients und eine Veröffentlichung im Store werden nicht als geprüft angegeben.

Skill-Injektion für KI-Clients (2026-09-17)

• Vor dem Push wurde der gestagte Snapshot, der ausschließlich die Skill-Dateien enthält, in ein isoliertes Verzeichnis exportiert und bestand cargo test -p memories --locked --bin memories --test skill_injection --test localization: 25 bestanden, keine Fehler, vier bewusst ignorierte Subprozess-Hilfsprogramme. Die Formatierung besteht dort ebenfalls.
• Vollständige Prüfung der Arbeitskopie einschließlich der bereits vorhandenen Wiki-/Zwischenablageänderungen: cargo test --workspace --locked -- --test-threads=2: 127 bestanden, keine Fehler, zehn bewusst ignorierte Subprozess-Hilfsprogramme, die von übergeordneten Szenarien aufgerufen werden. Bestehende Regressionen für Autorisierung, MCP, Speicherung, Synchronisierung, FFI und Relay bestehen zusammen mit den neuen Installationstests.
• Windows: neun neue Regressionen bestehen (drei Unit-Tests und sechs CLI-Integrationstests). Sie decken Benutzer-/Projektverzeichnisse, Konfigurationsüberschreibungen, doppelte Ziele, gemeinsame Überschreibungspfade, Probelauf, Idempotenz, ausdrückliches Ersetzen, Konfliktvorprüfung, ungültige Eingaben, Erhaltung benachbarter Dateien und Hilfe in fünf Sprachen ab. Die Tests verwenden temporäre Verzeichnisse und starten keinen Daemon und initialisieren keinen Memories-Speicher.
• Eine separate Windows-Junction-Prüfung bestätigt, dass --force ein verknüpftes Skill-Verzeichnis abweist, bevor andere Ziele beschrieben werden, und dessen ursprüngliche Datei erhält. Die Unix-Symlink-Regression ist enthalten, wurde auf diesem Host jedoch nicht ausgeführt.
• cargo build --workspace --locked, cargo fmt --all --check, cargo clippy --workspace --all-targets --locked -- -D warnings und git diff --check bestehen. Vorhandene Hinweise zur zukünftigen Kompatibilität von Rust-Abhängigkeiten und informative FFI-Linker-Warnungen bleiben bestehen.
• Die skill-creator-Prüfung quick_validate.py besteht. cargo package -p memories --list --allow-dirty --locked bestätigt, dass die mitgelieferte SKILL.md mit dem CLI-Paket ausgeliefert wird. Die Installation erfordert keinen Netzwerkzugriff.
• Die Erkennungspfade wurden mit der aktuellen Dokumentation von Codex, OpenCode und Claude Code abgeglichen. Live-Client-Erkennung/Modellverhalten, Linux-/macOS-Ausführung, Claude Desktop/Cowork und Cloud-Skill-Uploads wurden nicht geprüft. Während der Prüfung wurden keine persönlichen Skill-Verzeichnisse oder Client-Konfigurationen geändert.

Wiki-Geheimnisreferenzen und Zwischenablage (2026-09-17)

• Windows-Rust-Workspace: 118 bestanden, keine Fehler, zehn bewusst ignorierte Subprozess-Hilfsprogramme, die von übergeordneten Szenarien aufgerufen werden. Workspace-Build, Rust-Formatierung und Prüfungen auf Whitespace-Fehler im Diff bestehen. Die aktualisierten CLI-, IPC- und FFI-Pfade wurden nach ihren abschließenden Änderungen außerdem in gezielten Läufen geprüft.
• Vier Core-Funktionsregressionen bestehen: exaktes Ersetzen, sichere Projektionen, lokale Rechteerhöhung/MCP-Isolation, Ablehnung von Metadaten (einschließlich durch Escape-Sequenzen codiertem Text), Kopien geschützter Karten, Ablehnung von Binärdaten/NUL, Synchronisierung, Persistenz und unabhängige Wiederherstellung aus einem Backup. Ein zusätzlicher gezielter Lauf prüft das atomare Zurückrollen, wenn das Ersetzen ein Dokument nach der Vorbereitung der Zugangsdaten über die Größenbegrenzung des Inhalts hinaus erweitert. Signierte historische Inhalte bleiben absichtlich unverändert.
• Die echte CLI-/Daemon-IPC-Suite besteht (drei Tests und vier ausdrücklich aufgerufene Subprozess-Hilfsprogramme), einschließlich Ersetzen, maskierten Lesezugriffen und autorisierter Kopieübermittlung. Die FFI-Regression besteht mit denselben JSON-Operationen und verweigert Kopien nach nativer Sperrung. Alle Testumgebungen verwenden synthetische Geheimnisse und temporäre Speicher; es wurden kein installierter Speicher und keine Benutzerzwischenablage verwendet.
• Flutter: 36 Tests bestanden, einschließlich fünf neuer Fälle für verborgene Ersetzungseingaben, Rechteerhöhung vor Schreibzugriffen auf die Zwischenablage, verworfene verspätete Antworten nach Hintergrundsperrung, Kopierfehler und Erhaltung von Referenzen beim Bearbeiten. Die Übermittlung an die Zwischenablage verwendet einen simulierten Plattformkanal. Flutter-Analyse, Dart-Formatierung und Clippy für den Workspace/alle Ziele mit -D warnings bestehen.
• Native Windows-Zwischenablageaufrufe kompilieren, wurden aber nicht gegen die interaktive Zwischenablage geprüft. Linux-/macOS-Zwischenablagehelfer und die Übermittlung an die Zwischenablage mobiler Betriebssysteme wurden nicht ausgeführt. Es war kein Android-Gerät angeschlossen und im konfigurierten SDK kein NDK installiert; Android-Bibliotheken/APK und iOS-Artefakte wurden nicht neu gebaut.
• Protokolle: target/wiki-secret-tests.log, target/wiki-atomic-tests.log, target/wiki-ipc-tests.log, target/wiki-ffi-tests.log, target/wiki-flutter-tests.log, target/wiki-clippy.log, target/wiki-workspace-tests.log und target/wiki-build.log.

Gespeicherte Spracheinstellungen (2026-09-17)

• CLI-Tests: 19 bestanden, acht bewusst ignorierte Subprozess-Hilfsprogramme. Persistenztests starten separate CLI-Prozesse mit temporären Home-Verzeichnissen und prüfen Speichern/Ersetzen einer Einstellung, Start- und Hilfeauswahl, Isolation je Home-Verzeichnis, vorübergehende Überschreibungen, Löschen der Einstellung, fehlerhafte Einstellungen und Bereinigung nach fehlgeschlagenen Schreibvorgängen.
• Flutter-Tests: 31 bestanden. Neue Regressionen prüfen, dass Änderungen der System-Locale im laufenden Betrieb die Oberfläche und den Schriftarten-Fallback aktualisieren, ohne eine Einstellung zu speichern. Gespeicherte Auswahlwerte bleiben fest; das Zurücksetzen auf die Systemstandardeinstellung bleibt über einen Neustart hinweg erhalten.
• Flutter-Analyse, Clippy für den Workspace/alle Ziele mit -D warnings, Rust-/Dart-Formatierung und Prüfungen auf Whitespace-Fehler im Diff bestehen. Native Geräte wurden nicht geprüft.
• Protokolle: target/i18n/persistence-rust.txt und target/i18n/persistence-flutter.txt.

Client und CLI in fünf Sprachen (2026-09-17)

Host: Windows x86_64, Rust 1.98.1 MSVC, Flutter 3.44.2 / Dart 3.12.2.

• Rust-Workspace-Tests: 112 bestanden, zehn bewusst ignorierte Subprozess-Hilfsprogramme. CLI-Lokalisierungstests bestehen ebenfalls mit den abschließenden CLI-Änderungen.
• Flutter-Widget-/Unit-Tests: 29 bestanden, einschließlich fünf Systemsprachen, englischem Fallback, persistierter Sprachauswahl, Erhaltung entsperrter Sitzungen, Dialogen in Telefonbreite, Pluralzahlen und Maskierung geschützter Vorschauen.
• Flutter-Analyse, Rust-/Dart-Formatierung, Clippy für den Workspace/alle Ziele mit -D warnings und Prüfungen auf Whitespace-Fehler im Diff bestehen. Vorhandene Hinweise zur zukünftigen Kompatibilität von Rust-Abhängigkeiten bleiben bestehen.
• CLI-Hilfe, verschachtelte Hilfe, Locale-Rangfolge und lokalisierte nicht interaktive Fehler wurden über die tatsächliche Binärdatei geprüft. JSON-Felder und Fehlercodes bleiben stabil. Widget-Screenshots wurden bei 390 x 844 mit im Test geladenen Schriftarten gerendert.

Lokale Protokolle liegen unter target/i18n/. Der HTTP-Proxy des Hosts wurde für Flutter-Loopback-Testverbindungen ausgeschlossen. Für diese Lokalisierungsänderung wurden kein Android-/iOS-Gerät, kein nativer Dateiauswahldialog, kein Live-OAuth-Anbieter und keine Linux-/macOS-Laufzeit geprüft.

Nachprüfung zu Cloud-Wiederherstellung und Widerruf (2026-09-17)

Host: Windows x86_64, Rust 1.98.1 MSVC. Regressionstestumgebungen verwenden synthetische Daten, temporäre verschlüsselte Datenbanken und ausschließlich Loopback-HTTP.

• cargo test --workspace --locked -j 2 --no-fail-fast -- --test-threads=2: 106 bestanden, zehn bewusst ignorierte Subprozess-Hilfsprogramme. Dies umfasst alle 24 Cloud-Synchronisierungs-/HTTP-Integrationstests.
• cargo fmt --all --check und Clippy für den Workspace/alle Ziele mit -D warnings bestehen. Die vorhandenen Hinweise zur zukünftigen Kompatibilität von Abhängigkeiten bleiben bestehen.

Die Regressionssuite deckt beschädigte Download-Antworten mit anschließenden fehlerfreien Wiederholungen, die weiterhin klare Trennung abgewiesener Objekte von erfolgreichen Importen und einen einmaligen erneuten Scan alter Empfangsbestätigungen ab. Sie prüft außerdem Downloads von Abhängigkeiten bei vollem Posteingang, das Verdrängen nicht referenzierter Envelope-Puffer und Verzeichnis-Cursor, die auf einer nur teilweise aufgenommenen Seite verbleiben.

Widerrufstests decken sowohl eingereihte Daten ab, die niemals gesendet werden dürfen, als auch einen bereits laufenden Upload: Letzterer darf abgeschlossen werden, aber die nächste Anfrage wird verhindert und seine veraltete Bestätigung abgewiesen. Die Google-Drive-Testumgebung akzeptiert doppelte Namen und weist ausschließlich doppelte Datei-IDs ab. Ihr Neustarttest unterbricht den Worker, nachdem der Server eine Datei angenommen hat, prüft, dass die ID bereits lokal gespeichert war, und prüft anschließend, dass die Wiederholung genau einen Envelope und einen Deskriptor erzeugt.

Die HTTP-Testumgebung versetzt angenommene Sockets unter Windows ausdrücklich in den blockierenden Modus; andernfalls können sie den nicht blockierenden Modus des Listeners übernehmen und Verbindungen zurücksetzen, bevor Anfragebytes eintreffen. Die In-Memory-Testumgebung verbirgt bei der Simulation einer unvollständigen Veröffentlichung Objekte jetzt sowohl in Auflistungen als auch bei direkten Downloads.

Für diese Nachprüfung wurde kein Live-Cloud-Konto und kein natives Android-/iOS-Gerät verwendet. Die nachstehend dokumentierten Grenzen der Plattform- und Release-Abnahme gelten weiterhin.

Nachprüfung zu Zuverlässigkeit und mobiler Cloud (2026-09-17)

Host: Windows x86_64, Rust 1.98.1 MSVC, Flutter 3.44.2 / Dart 3.12.2. Durchgehend wurden synthetische Geheimnisse und temporäre Datenbanken verwendet.

• Die Tests des Rust-Workspace bestehen, einschließlich der Regression für einen blockierten Client und das Sperren beim echten Daemon. Gezielte Tests prüfen zusätzlich, dass eine blockierte Cloud-HTTP-Anfrage das Sperren zulässt, gleichzeitige Anbieterläufe abgewiesen werden und eine verspätete Bestätigung eine ungültig gewordene Sitzung nicht wiederherstellen kann.
• Cloud-Regressionstests decken normale OneDrive-Download-Weiterleitungen ohne Weitergabe von Bearer-Tokens, Weiterleitungsschleifen/unsichere Ziele, anbieterspezifisches Einreihen und Wiederverbinden, die Verdichtung abgeschlossener Warteschlangeneinträge über die bisherigen Grenzen von 256/4096 hinaus und Wiederholungsversuche für vorübergehend fehlende Objekte nach einer Wartezeit ab. Widerrufene Empfänger blockieren die Vorbereitung für aktive Geräte nicht mehr und halten einen Tresor nicht dauerhaft im Zustand mit ausstehenden Änderungen. Die HTTP-Testumgebung bleibt nun bestehen, bis ihr Besitzer sie beendet, statt nach 30 Sekunden abzulaufen.
• Der Windows-FFI-Test prüft ausstehende Hintergrundsperren sowohl bei belegten als auch bei inaktiven Handles und den Aufruf über den nativen Cloud-Worker. Die native OAuth-Validierung weist unsichere Callbacks und fehlerhaftes PKCE vor Netzwerk-I/O zurück.
• Rust-Formatierung und Clippy für den Workspace/alle Ziele mit -D warnings bestehen. Bestehende Hinweise zur zukünftigen Kompatibilität von russh/proc-macro-error2 bleiben bestehen.
• Die Flutter-Analyse und alle 16 Widget-Tests bestehen, einschließlich Kontostatus und manuellem Sperren während einer laufenden Synchronisationsanfrage. Rust-Zugriffs-/Aktualisierungstokens werden niemals an Dart zurückgegeben; AppAuth liefert den Autorisierungscode/Verifier.
• Der Release-Speicherbenchmark läuft mit 10, 100 und 1000 synthetischen Datensätzen. Ergebnisse und Metrikdefinitionen stehen in Leistung. Beim Anhängen an das Audit-Protokoll wird nicht mehr für jeden vorherigen Eintrag derselbe öffentliche Geräteschlüssel abgeleitet.
• Workflow-YAML, eingebettetes Python für die Signierungskonfiguration, Unicode-Escaping für Java-Properties, Markdown-Links/Codeblöcke und Leerraum im Diff werden lokal geprüft.

Die Installation von Android SDK/NDK/Emulator wurde versucht, aber die Übertragung großer offizieller Archive war zu langsam, um sie während dieses Durchlaufs abzuschließen. Für diese Änderung wird kein Ergebnis für ein Android-APK oder native Geräte beansprucht. iOS-Builds benötigen macOS und wurden nicht ausgeführt. Die neuen nativen CI-Jobs und der manuelle Android-Signierungsworkflow wurden nicht remote ausgeführt. Es handelt sich um konfigurierte Prüfungen, nicht um verifizierte Build-Artefakte.

Es wurden weder ein registrierter nativer OAuth-Client, eine echte Cloud-Zustimmung, eine signierte Distribution, ein Lauf auf einem physischen Gerät noch eine unabhängige Sicherheitsprüfung durchgeführt. Die Unterstützung nativer Google-Weiterleitungen muss für Android und iOS mit der gewählten Registrierung getrennt validiert werden. Siehe Release-Checkliste für Abnahmekriterien. Installierte memories-Binärdateien und echte Benutzertresore wurden nicht ersetzt.

Projektbenennung für die Erstveröffentlichung (2026-09-17)

Projekt, Repository, CLI, Rust- und Dart-Pakete, FFI-Symbole und Header, Android-/iOS-Kennungen, Speichernamen, Umgebungsvariablen und kryptografische Domänen verwenden nun durchgängig memories. Diese Erstveröffentlichung bietet keine Aliase früherer Namen oder Migrationspfade. Das Repository ist https://github.com/mbcc2006/memories.

Host: Windows x86_64, Rust 1.98.1 MSVC, Flutter 3.44.2 / Dart 3.12.2.

• cargo test --workspace --locked -j 2 -- --test-threads=2: 89 bestanden, zehn absichtlich ignorierte Hilfstests für Unterprozesse.
• cargo fmt --all --check und Clippy für den Workspace/alle Ziele mit -D warnings: bestanden.
• cargo build --workspace --release --locked -j 2: bestanden; die CLI-Version und die Relay-Hilfe geben beide den neuen Namen aus.
• Sechs Release-Smoke-Tests für CLI/Daemon/FFI bestanden mit einer temporären Bibliothek: native Initialisierung/Schreiben/Sicherung, Entsperren/Lesen über den Daemon, Auswahl über MEMORIES_HOME, Lesen und Sperren/Entsperren über die CLI, Wiederherstellung einer nativen Sicherung und Sperren aktiver nativer Handles durch den Export memories_lock_all.
• Dart-Formatierung und flutter analyze: bestanden. Flutter-Widget-Tests: 14 bestanden. Der erste Widget-Durchlauf konnte wegen des HTTP-Proxys des Hosts keine Verbindung zum lokalen Testrunner herstellen; eine Wiederholung mit entfernten Proxy-Variablen für diesen Prozess und Loopback in NO_PROXY bestand.

Lokale Nachweise liegen in target/rename-tests.log, target/rename-clippy.log, target/rename-release-build.log, target/rename-e2e.log, target/rename-e2e-report.json, target/rename-flutter-analyze.log und target/rename-flutter-tests.log. Der E2E-Bericht bindet sein Ergebnis an den CLI-Hash. Android-APK-/iOS-Builds und native Geräteintegrationstests wurden bei dieser Umbenennung nicht ausgeführt. Die Proxy-E2E-Ergebnisse mit echten Diensten im nächsten Abschnitt beschreiben ihren früheren Build; dieser Abschnitt hält die lokalen Smoke-Tests der neuen Veröffentlichung fest.

SSH-/Datenbank-Proxys und Release-E2E (2026-09-16)

Host: Windows x86_64, Rust 1.98.1 MSVC. Die Release-CLI und der Daemon wurden mit temporären OpenSSH-8.9p1-, PostgreSQL-14.24-, MySQL-8.0.46- und Redis-6.0.16-Servern in Ubuntu 22.04 WSL getestet. Serverpakete wurden in ein privates temporäres Verzeichnis mit unabhängigen Daten, Zertifikaten und synthetischen Konten extrahiert; es wurden keine Systemdienste installiert. Der Test-Daemon verwendete ein temporäres --home. Alle Testserver wurden anschließend beendet und ihre Daten/privaten Schlüssel entfernt.

• Workspace-Regression: 88 bestanden, zehn absichtlich ignorierte Hilfstests für Unterprozesse. Befehl: cargo test --workspace --locked -j 1 -- --test-threads=1.
• Nachfolgende Korrekturen für Kurz-IDs bestanden alle neun Remote-Tests und das echte Daemon-IPC-Szenario. Die abschließende Korrektur des Herunterfahrens bestand die vier Proxy-Tests, beide IPC-Szenarien und eine zusätzliche Regression für sofortiges Beenden/Sperren ohne Wartezeit/Join beim Herunterfahren im Testclient. Diese gezielten Durchläufe folgen auf den vollständigen Workspace-Durchlauf.
• Die abschließenden Prüfungen mit Clippy für den Workspace/alle Ziele mit -D warnings, der Rust-Formatierung und dem Leerraum im Diff bestanden. Bestehende Hinweise zur zukünftigen Kompatibilität der Abhängigkeiten russh und proc-macro-error2 bleiben bestehen; kein Lint-Fehler wurde unterdrückt.
• cargo build --workspace --release --locked -j 2 bestand. Die neu gebauten Befehle für CLI-Version/-Hilfe und Relay-Hilfe liefen erfolgreich. Der installierte Daemon und die Benutzerdaten wurden nicht ersetzt.
• 11 E2E-Prüfungen mit echten Diensten bestanden mit scripts/test-proxy-e2e.py gegen die neu gebaute Release-Binärdatei. OpenSSH- und SFTP-Clients, psycopg2, PyMySQL und redis-py verbanden sich ohne Geheimnisse der Zieldienste mit vom Daemon erstellten Loopback-Proxys.

Die E2E-Abdeckung umfasst den Import von Zugangsdaten per Kurz-ID und die Verweigerung des Lesens von Geheimnissen; Ablehnung abweichender SSH-Hostschlüssel; Weiterleitung von stdout, stderr und Exit-Status; SFTP-Upload/-Download; Ablehnung nicht vertrauenswürdiger PostgreSQL-TLS-Verbindungen; PostgreSQL-SCRAM, verifiziertes TLS, Unicode und Transaktions-Rollback; MySQL-caching-SHA-256, verifiziertes TLS und Vier-Byte-Unicode; Redis AUTH über TLS; Isolation der MCP-Rechteerhöhung; explizites Beenden ohne Unterbrechung anderer Proxys; und das Schließen aller Listener sowie bereits bestehender SSH-/Datenbankverbindungen beim Sperren.

Der erste E2E-Durchlauf zeigte, dass proxy stop zurückkehrte, während die Annahmeschleife noch bis zu 200 ms lang Anfragen weiterleiten konnte. Der Dienst besitzt nun den Proxy-Worker und wartet per Join auf dessen Ende, bevor er Beenden/Sperren bestätigt. Der abschließende E2E-Wiederholungslauf prüft die Trennung unmittelbar nach der Antwort und besteht.

Lokale Nachweise: target/proxy-20260916-workspace-tests.log, target/proxy-20260916-remote-tests.log, target/proxy-20260916-shutdown-tests.log, target/proxy-20260916-close-regression.log, target/proxy-20260916-clippy.log, target/proxy-20260916-release-build.log, target/proxy-20260916-e2e.log und target/proxy-e2e/results/report.json. Der Bericht bindet das E2E-Ergebnis an den folgenden CLI-SHA-256. Das wiederverwendbare Skript benötigt extern bereitgestellte temporäre Testumgebungen, wie in seiner Moduldokumentation beschrieben; es installiert keine Server.

Android-/iOS-Artefakte und native Laufzeittests wurden bei dieser Änderung der Desktop-Proxys nicht neu gebaut oder ausgeführt. Es wurden keine produktiven SSH-/Datenbankkonten oder echten Cloud-Konten verwendet.

Synchronisierung von Cloud-Objekten (2026-09-16)

Ein anbieterneutraler Runner für unveränderliche Objekte mit dauerhaften Outbox-/Inbox-Belegen wurde hinzugefügt. Die Abdeckung befindet sich in den Unit-Tests von crates/core/src/sync.rs und in crates/core/tests/cloud_sync.rs:

• Die exakten Envelope-Bytes bleiben über das erneute Öffnen des Prozesses hinweg erhalten; ein fehlgeschlagener Put-Vorgang wiederholt dieselbe Objekt-ID ohne erneute Verschlüsselung.
• Ein doppelter Put-Vorgang lädt das vorhandene Objekt herunter und prüft es, bevor der Auftrag als hochgeladen markiert wird.
• Ein vor seinem Envelope aufgelisteter Deskriptor bleibt ausstehend; nach Bereitstellung des Envelopes sowie Umordnung/Duplizierung der Auflistung erfolgt weiterhin genau ein Import.
• Ein beschädigter Download wird als corrupt erfasst und führt keinen Tresorzustand zusammen.
• Sperren und Abmelden erhöhen die Synchronisationssitzung, sodass ein verspätetes CloudSyncAck keinen Import auslösen kann; unvollständige Outbox-Aufträge bleiben nach dem Entsperren im verschlüsselten Zustand, bis sie durch Abmelden abgebrochen werden.
• Zwei gekoppelte Geräte tauschen gleichzeitige Änderungen über MemoryTransport aus.
• Ausschließlich lokale Tresore und MCP-Aufrufer können weder Arbeit einreihen noch einsehen. Sicherungen und wiederhergestellte Bibliotheken haben ein leeres cloud_sync und keine Cloud-Konten.

Daemon-eigene SSH-/FTP-/TCP-Sitzungen mit Vorschlagen/Genehmigen/Ausführen pro Anweisung wurden hinzugefügt (crates/core/src/remote.rs, crates/core/tests/remote.rs). MySQL-, Redis- und PostgreSQL-Sitzungen behalten ihren Zustand auf der aktiven Verbindung und aktivieren TLS standardmäßig (Hostnamenprüfung; optionale Zugangsdaten mit PEM-CA). --no-tls ist explizit. Echte Datenbank-TLS-Handshakes wurden nicht ausgeführt. Die Erzeugung von SSH-/TLS-Schlüsseln hält private Schlüssel im Zugangsdaten-Speicher; Tests stellen sicher, dass Antworten für Erzeugung/öffentliche Schlüssel kein PEM mit privatem Schlüssel enthalten. Loopback-SSH-/Redis-Proxys fügen gespeicherte Zugangsdaten ein, damit sich ein lokaler Client ohne das Geheimnis verbinden kann; Sperren setzt das Stopp-Flag des Proxys. Echte Konten wurden nicht verwendet.

Token-Aktualisierung, OneDrive-/Google-Drive-Adapter, CloudSyncRun des Daemons und memories cloud sync wurden hinzugefügt. Die Abdeckung befindet sich in den Aktualisierungstests von cloud.rs und den Loopback-Testumgebungen in crates/core/tests/cloud_drive.rs. Echte Microsoft-/Google-Konten wurden nicht autorisiert. Eine mobile Anmelde-/Synchronisierungsoberfläche wurde nicht hinzugefügt.

Lokale Prüfung am 2026-09-16 (Windows x86_64, rustc 1.98.1 GNU, MinGW-w64 GCC 16.2.0):

• cargo test -p memories-core --locked -j 1 -- --test-threads=1: 49 bestanden, zwei absichtlich ignorierte Hilfstests für Unterprozesse.
• cargo clippy -p memories-core --all-targets --locked -- -D warnings: bestanden.
• cargo fmt --all: bestanden.

Repository-Prüfung (2026-09-09)

• Windows-Rust-Workspace: 51 bestanden, keine Fehler. Zehn absichtlich ignorierte Hilfstests für Unterprozesse werden explizit von ihren übergeordneten Tests gestartet. Befehl: cargo test --workspace --locked -j 1 -- --test-threads=1.
• Initialisierungstests beenden einen Prozess nach der Bereitstellung und vor der Veröffentlichung und erstellen/entsperren den Speicher anschließend erfolgreich erneut. Vorhandene Ziele, einschließlich einer während der Initialisierung erscheinenden Datei, bleiben intakt; die Betriebssystemsperre des Ziels bleibt bis zum Abschluss der Veröffentlichung gehalten. Dies simuliert keinen physischen Stromausfall.
• Die Erfassung von Zugangsdaten weist doppelte JSON-Schlüssel zurück, einschließlich verschachtelter Objekte und durch Escaping gleichwertiger Namen. Tests erhalten gültiges Array-/Zeiger-/String-Verhalten, Fehlerredaktion und Zurückweisung über tatsächliche CLI-/Daemon-IPC.
• Eine verzögerte HTTP-Profil-Testumgebung bestätigt, dass OAuth-Netzwerklatenz die Gültigkeit von Zugriffstokens nicht verlängern kann. Bestehende Regressionen für den Austausch mit Anbietern und Abbruch durch Sperren/Abmelden bestehen. Relay-WebSocket-Tests enthalten nun Ping/Pong; Steuerantworten verwenden dasselbe Sendezeitlimit von zehn Sekunden wie Daten in der Warteschlange. Ein Dauertest mit gesättigtem Socket wurde nicht durchgeführt.
• Clippy für den Workspace/alle Ziele mit -D warnings, Rust-/Dart-Formatierung, Leerraum im Diff und lokale Prüfungen von Markdown-Links/Codeblöcken bestanden. Die Flutter-Analyse meldete keine Probleme; alle 14 Widget-Tests bestanden.
• Die neu gebaute Windows-FFI bestand temporäre Prüfungen mit synthetischen Daten für erfolgreiche Initialisierung ohne verbliebene Staging-Dateien, Ablehnung veralteter Tickets nach dem Sperren, verschlüsselte Kontopersistenz über erneutes Öffnen hinweg, Status nur mit Metadaten und lokale Abmeldung. Die Testumgebung wurde anschließend entfernt.
• Lokale Protokolle: target/review-20260909-rust-tests.log, target/review-20260909-clippy.log und target/review-20260909-flutter-tests.log. Rust verwendete D:/memories-build-cache/cards mit einem Build-Job/Test-Thread.
• Bei dieser Prüfung wurden weder echte Microsoft-/Google-Autorisierung, native Android-/iOS-Ausführung noch Linux-/macOS-Laufzeitprüfungen durchgeführt. Installierte Binärdateien wurden nicht ersetzt; Remote-CI und Release-Artefakte wurden nicht validiert.

Cloud-Autorisierung (2026-09-09)

• Windows-Rust-Workspace: 47 Tests bestanden, einschließlich Regressionen für Cloud-Autorisierung und Speicherfehler. Neun Hilfstests sind von der automatischen Erkennung ausgeschlossen und werden explizit von ihren übergeordneten Szenarien gestartet.
• Clippy für den Workspace/alle Ziele mit -D warnings, Rust-Formatierung und Leerraumprüfungen im Diff bestanden. Auf die abschließende nicht blockierende Anpassung des Browserstarts folgten die CLI-Cloud-Tests, Clippy und ein neuer CLI-/FFI-Build.
• Beide OAuth-Anbieter wurden mit lokalen HTTP-Testumgebungen geprüft: PKCE, State, Kontoidentität, Bereichsprüfungen, fehlende Aktualisierungstokens, Antwortlimits, zurückgewiesene Weiterleitungen und allgemeine Fehler ohne Wiedergabe von Geheimnissen.
• Ein Test mit einem echten Loopback-Socket wies einen unpassenden Callback zurück und akzeptierte den passenden Callback, ohne dessen Code in der HTTP-Antwort wiederzugeben.
• Core-Regressionen prüften die Bindung von Aufrufer und Anbieter, Replay, Abbruch durch Sperren/Abmelden, verschlüsselte Persistenz, Audit-/MCP-Isolation und das Fehlen von Cloud-Tokens in entschlüsselten Sicherungs- und Synchronisationsdaten.
• Eine temporäre Windows-FFI-Testumgebung mit synthetischen Tokens bestand die Autorisierungspersistenz über Schließen/erneutes Öffnen hinweg, den Abbruch durch memories_lock_all und die Abmeldung. Die Testumgebung wurde anschließend entfernt.
• Es wurden weder eine registrierte Client-Konfiguration noch ein echtes Cloud-Konto bereitgestellt; echte Microsoft-/Google-Zustimmung und Token-Ausgabe bleiben daher ungeprüft. Es wurden keine Cloud-Dateien hochgeladen. Kein Android-Gerät/Emulator war angeschlossen; die native Android-/iOS-Ausführung und die mobile Anmeldeoberfläche wurden bei dieser Änderung nicht validiert.
• Lokale Entwicklungsbinärdateien wurden gebaut; installierte CLI-/Daemon- Binärdateien wurden nicht ersetzt, und es wird kein Remote-CI- oder Release-Ergebnis beansprucht.

Validierung vor dem Push (2026-09-09)

• Rust-Workspace-Regression: 30 bestanden; zwei IPC-Kindprozess-Hilfstests werden weiterhin explizit durch das übergeordnete Szenario aufgerufen. Enthalten sind Kurz-ID-Kollision, Verlauf, geschützte Referenzen und Grant-Roundtrips.
• Clippy für den Workspace/alle Ziele mit -D warnings und Rust-Formatierung bestanden. Die Paritätsprüfung für Kurz-IDs wurde auf is_multiple_of aktualisiert; beide ID-Unit-Tests wurden nach dieser gleichwertigen Lint-Korrektur erneut bestanden.
• Die Dart-Formatierung, die Flutter-Analyse und alle 14 Widget-Tests wurden bestanden.
• Die Windows-Tests verwendeten D:/memories-build-cache/cards, einen Build-Job und einen Test- Thread. Alte PDB-Dateien, die LNK1201/LNK1207 verursachten, wurden vor der Neuerstellung mit dem Suffix .pre-push-20260909 aufbewahrt. Das erfolgreiche Workspace-Protokoll ist target/push-20260909-rust-tests.log.
• Release-Binärdateien und Android-Artefakte wurden bei dieser Prüfung nicht neu erstellt; die früheren Artefakt-Hashes weiter unten validieren das neue Kurz-ID-Protokoll nicht. Ergebnisse der entfernten CI werden gesondert erfasst.

Nachprüfung der Passwortlänge (2026-09-09)

Lokale Passwörter und Backup-Passwörter unterliegen auf Anwendungsebene keiner Mindest- oder Höchst- längenrichtlinie mehr. Leere Eingaben werden akzeptiert. Bestätigung, Argon2id-Parameter, Authentifizierung, sudo-Geltungsbereich und verschlüsselte Speicherung bleiben bestehen.

• Neue Core-Regression für die Längen 0, 1 und 4096 bestanden: Speichererstellung, Authentifizierung, Entsperren, Backup und Wiederherstellung; falsche Passwörter werden abgewiesen.
• Clippy für den Workspace/alle Targets mit -D warnings und die Rust-Formatierung wurden bestanden.
• Die Flutter-Analyse und alle 14 Widget-Tests wurden bestanden, einschließlich der Initialisierung mit leeren Passwörtern und Passwörtern mit einem Zeichen bei beibehaltenem Bestätigungsschritt.
• Windows-CLI/FFI neu erstellt und den lokalen Daemon neu gestartet. Eine separate temporäre Testkonfiguration gegen die Release-FFI bestand init/unlock/sudo mit einem Zeichen, ein leeres Backup-Passwort und die Wiederherstellung mit Schutz durch ein Passwort mit einem Zeichen.
• Beide Android-ABIs und die APK mit normalem Einstiegspunkt neu erstellt. Gleichheitsprüfungen der nativen Bibliotheken zwischen Quelle/zusammengeführter Ausgabe und Ausgabe ohne Symbole/APK wurden bestanden. Die Android-Laufzeitintegration wurde für diese ausschließlich die Länge betreffende Änderung nicht erneut ausgeführt; die native Testkonfiguration verwendet nun ein Passwort mit einem Zeichen für den nächsten Gerätetest.

Diese Hashes ersetzen die früheren Artefaktaufzeichnungen. Das Build-Protokoll ist target/password-length-android-build.log; detaillierte ABI-Hashes stehen in target/password-length-artifacts.json.

Nachprüfung von Karten, geschützten Metadaten und OTP

Die folgenden Funktionsprüfungen und Artefakte ersetzen die weiter unten in diesem Dokument aufgezeichneten Hashes des Basis-Builds. Alle bei der Validierung verwendeten Zugangsdaten waren synthetisch; es wurden keine bereitgestellten Kontozugangsdaten oder Mailserver verwendet.

• Rust-Workspace-Regression: 25 bestanden. Das erweiterte CLI-IPC-Szenario und die Prüfungen nach RFC 6238 sowie für fehlerhafte Eingaben wurden nach den letzten Testerweiterungen ebenfalls bestanden. Zwei Hilfstests werden bei der Testerkennung absichtlich ignoriert und ausdrücklich vom IPC-Szenario ausgeführt (Einfügen von Zugangsdaten und sudo aus einem Geschwisterprozess).
• Rust-Formatierung und Clippy für den Workspace/alle Targets mit -D warnings: bestanden. Die Windows-Debug-Prüfungen verwendeten D:/memories-build-cache/cards und -j 2.
• Flutter-Analyse und alle 12 Widget-Tests: bestanden. Die Abdeckung umfasst einen Graphen in Smartphone-Größe, gerichtete Rückverweise, maskierte Vorschauen, private OTP-Autorisierung, Ablauf und das Schließen des OTP-Dialogs beim Wechsel in den Hintergrund/Sperren.
• Den Windows-Release-Workspace neu erstellt. Eine echte Release-CLI mit einem temporären verschlüsselten Speicher erfasste Python 3.13.1 und dessen Verzeichnis der ausführbaren Datei, markierte den Tresor als ausschließlich lokal und fand die Beobachtung über die Kartensuche. Die Testkonfiguration und der Daemon wurden nach der Prüfung entfernt.
• ARM64/x86_64-Android-FFI-Bibliotheken neu erstellt. Der API-35-x86_64-Emulator bestand den echten FFI-Integrationstest: Karten/Verknüpfungen/Graph, dotenv-Suche nur nach Schlüsseln, TOTP- Generierung, verweigertes Lesen von Zugangsdaten, Audit und Sperren/Entsperren. Protokoll: target/cards-android-native-test.log.
• Nach dem Integrationstest die Entwicklungs-APK mit normalem Einstiegspunkt neu erstellt und installiert. Start, Passwortinitialisierung, Bibliothekserstellung und Öffnen des neuen Formulars für geschützte Karten waren erfolgreich. Die weitere manuelle Übermittlung des Kontoformulars wurde unterbrochen, als der Emulator aus ADB verschwand; dieses zusätzliche manuelle Szenario wird nicht als bestanden erfasst. Start-XML: target/cards-android-startup.xml; Build-Protokoll: target/cards-android-build.log.
• Die paketierten nativen Bibliotheken wurden pro ABI geprüft: Die Quelle entspricht der von Gradle zusammengeführten Ausgabe, und die Ausgabe ohne Symbole entspricht dem APK-Eintrag. Nachweise und Größen: target/cards-artifacts.json.

Die Core-Sicherheitstests decken separate verschlüsselte Speicherung von Zugangsdaten, atomisches Fehlschlagen, das Fehlen von Geheimnissen in Suche/Liste/Graph/MCP/Audit und Klartext-Datenbankbytes, die Verweigerung des Austauschs von Referenzen, Host-Beschränkung/Header-Injection, den Ausschluss ausschließlich lokaler Inhalte aus Kopplung/Synchronisierung/Backup und OTP-Referenzen nach Synchronisierung/Wiederherstellung ab. Die RFC-6238-Abdeckung umfasst alle sechs Standardzeitstempel für SHA-1/SHA-256/SHA-512, sowie sechsstellige Ausgabe und die Zurückweisung fehlerhafter Seeds/Perioden. HTTP-Header-Tests verwenden synthetische Werte und prüfen die Kennzeichnung sensibler Header; es wurde keine authentifizierte Anfrage an einen Produktionsdienst gesendet.

Aktuelle Artefakte (Entwicklungs-Build, nicht für die Verteilung signiert):

SHA-256 des paketierten Rust-Codes:

Die Plattformbeschränkungen am Ende dieses Dokuments gelten weiterhin. Dieser Abschnitt hält die lokale Validierung fest; hier wird kein Ergebnis einer entfernten CI behauptet.

Basisprüfung des Windows-Rust-Workspaces

Host: Windows x86_64, stabiles Rust 1.98, MSVC-Toolchain, gebündeltes SQLite.

Der ignorierte Test ist das vom IPC-Test verwendete ausführbare Kindprogramm und wird dort ausdrücklich mit eingefügten Zugangsdaten ausgeführt. Es handelt sich nicht um ein übersprungenes Sicherheitsszenario.

Die Tests prüfen authentifizierte Verschlüsselung und Transportmanipulationen, verschlüsselten SQLite-Zustand, falsche Passwörter, Checkpoint-Kürzung, Chunk-Reihenfolge, Berechtigungen, Gerätefreigabe und -widerruf, Verweigerung erneuter Identitätsautorisierung, gemeinsame Mitgliedschaft, Replay, gleichzeitige Revisionen, Auflösung von Richtlinienverzweigungen und unabhängige Backup-Wiederherstellung. Ein echter CLI-Daemon-Test deckt Entsperren, Terminal-sudo, verweigertes Lesen von Zugangsdaten, Freigabe anhand des Digests ausführbarer Dateien, Unterdrückung der Kindprozessausgabe, signiertes Audit, MCP-Geltungsbereich und Sperren ab. Ein echter WebSocket-Test prüft Live-Routing und Raumbereinigung nach dem Trennen der Verbindung.

Die Implementierung der Windows-Named-Pipes verwendet blockierendes Framing. Ein Versuch einer PIPE_NOWAIT-Implementierung scheiterte an der Regression mit echtem Daemon und wurde ersetzt; Verfügbarkeitsgrenzen gegenüber demselben Benutzer sind in SECURITY.md dokumentiert.

Windows-Basisartefakte (Pfade relativ zum Checkout; Build-Ausgaben werden von Git ignoriert). Die CLI bestand außerdem die Ausführung von --version und --help:

Flutter und native mobile Bibliotheken

Toolchain: Flutter 3.44.2 / Dart 3.12.2, Android NDK 28.2.13676358, Android-SDK-Plattformen 35, 36 und 37.0, Gradle 9.1.0.

Widget-Tests prüfen, dass ein Fehler beim nativen Start die Bibliothek gesperrt lässt, der Wechsel in den Hintergrund Inhaltsdialoge schließt und den Autorisierungszustand löscht und auch der Ablauf bei Inaktivität einen bereits geöffneten Inhaltsdialog schließt. Verspätete asynchrone Antworten werden nach einer Änderung der mobilen Autorisierungsgeneration verworfen. Der native Integrationstest verwendet eine temporäre Datenbank auf dem Gerät statt eines Mock-Backends. Er initialisiert den echten Rust-Dienst, schreibt und liest Erinnerungen, verlangt erhöhte Berechtigungen zum Hinzufügen von Zugangsdaten, verweigert das Lesen von Zugangsdaten, überprüft die Audit-Kette, sperrt alle nativen Handles und entsperrt persistierte Inhalte, ohne erhöhte Berechtigungen wiederherzustellen. Das Testverzeichnis wird nach dem Test entfernt.

Der Emulator führt ein vorhandenes API-35-x86_64-Image im schreibgeschützten Modus aus, ohne einen Snapshot zu speichern. Die Testausgabe ist lokal verfügbar unter target/android-native-test.log. Der Android-Build gibt eine Warnung zur alten SDK-XML-Version von einer Plugin-Toolchain aus, die jedoch weder die Kompilierung noch die native Ausführung verhinderte. Das Compile-SDK der App ist 37, um die Anforderungen des Secure-Storage-Plugins zu erfüllen.

Die abschließende APK mit normalem Einstiegspunkt wurde nach den Integrationstests neu erstellt, installiert und durch Android-UI-Automatisierung geprüft. Die Prüfungen bestanden für den Start mit dem tatsächlichen Secure-Storage-Plugin, die Passwortinitialisierung, das Erstellen einer Bibliothek und Erinnerung, das Lesen dieser Erinnerung, den Wechsel in den Hintergrund bei geöffnetem Inhalt, die Rückkehr zu einem gesperrten Bildschirm und das Entsperren zum erneuten Lesen persistierter Inhalte. Damit wird die normale App geprüft, nicht nur der Einstiegspunkt des Integrationstests. UI-Nachweise sind gespeichert in target/android-ui-startup.xml, target/android-ui-initialized.xml, target/android-ui-memory-saved.xml, target/android-ui-content-open.xml, target/android-ui-background-locked.xml und target/android-ui-unlocked-persisted-content.xml. Es wurden ausschließlich synthetische Testdaten verwendet. Der schreibgeschützte Emulator wurde nach der Überprüfung beendet.

Basis-APK: mobile/build/app/outputs/flutter-apk/app-debug.apk, 177,630,089 Bytes. SHA-256: 1d671906316c139eca786e89a5cca2c5d7895a825c0d58f4c32e71e6ff8be382. Dies ist eine mit Debug-Schlüssel signierte Entwicklungs-APK, keine Store-Veröffentlichung.

Sowohl arm64-v8a als auch x86_64 enthalten die Flutter-Engine und die Rust-FFI-Bibliothek. Die JNI-Quellbibliotheken entsprechen den von Gradle zusammengeführten Bibliotheken; die von Gradle von Symbolen bereinigten Bibliotheken entsprechen dem Inhalt der endgültigen APK. Das Entfernen von Symbolen erklärt, warum ein direkter Hash-Vergleich zwischen Quelle und APK abweicht. SHA-256-Werte der paketierten Rust-Bibliotheken:

Der Windows-Debug-Build-Cache wurde nach D:/memories-build-cache/20260908/windows-debug verschoben, um Speicherplatz für die Emulator- Validierung freizugeben. Quelldateien und Release-Artefakte verbleiben im Checkout. Android- Builds verwendeten ein aufgabenspezifisches target/gradle-home, um die veraltete Proxy- Konfiguration des Hosts zu umgehen, sowie ein lokales Repository mit den exakt passenden Flutter-Engine-JARs, die anhand offizieller HTTPS-Metadaten überprüft wurden. Weder Engine-Code noch Plugin-Cache-Quellen wurden verändert. Die Verzeichnisse caches, wrapper und jdks in diesem Gradle-Home sind Junctions zum Gradle-Cache des Hosts.

Plattformen und verbleibende Validierung

• Laufzeitprüfungen für Linux- und macOS-Desktops wurden auf diesem Windows-Host nicht ausgeführt. Android-Cross-Kompilierung belegt keine Laufzeitkorrektheit unter Linux oder macOS.
• iOS-Xcode-Kompilierung, Simulator-/Geräteausführung, Signierung, Keychain-Verhalten und der native XCTest erfordern einen macOS-Host und wurden hier nicht ausgeführt.
• Die Ausführung auf physischen Android-ARM64-Geräten wurde nicht geprüft; erfolgreiche Cross-Kompilierung allein belegt weder das Hardwareverhalten noch Garantien der sicheren Speicherung.
• CI definiert Rust-Prüfungen für Windows/Linux/macOS und Flutter-Prüfungen, aber es werden keine Ergebnisse einer entfernten CI behauptet. Es fand keine Release-Signierung oder Store-Veröffentlichung statt.
• Es wurden keine unabhängige kryptografische Prüfung, kein Penetrationstest und kein Ressourcen- test in großem Maßstab durchgeführt. Vor der Verwendung echter Geheimnisse siehe SECURITY.md.

Client-Standardwerte und Skill-Generierung (2026-10-01)

• memories default set/get/delete durchlaufen einen vollständigen Zyklus mit einem temporären --home, weisen unbekannte Schlüssel und ungültige type-Werte zurück und entfernen defaults.json, wenn es leer ist.
• Listenbefehle wenden die Standardwerte für vault / type / category an, wenn Flags ausgelassen werden.
• Persona-Befehle für Welt/Ding/Ereignis lösen ausgelassene Tresore/Assets anhand der Standardwerte für persona / vault auf (VAULT/ASSET, Schrägstrichform oder Asset mit Tresor-Standardwert).
• memories skill generate / agents generate schreiben AGENTS.md oder ein SKILL.md im Skill-Layout offline ohne Persona; sie verweigern das Überschreiben ohne --force.
• cargo test --workspace --locked deckt Unit- und Integrationstests für diese Pfade ab.