Memories

Memories / Dokumentation

Auf dieser Seite

    Abnahme einer Veröffentlichung

    Führen Sie jede Prüfung für den Commit und das Artefakt aus, die veröffentlicht werden. CI-Definitionen und historische Ergebnisse sind kein Beleg dafür, dass eine neue Veröffentlichung bestanden hat. Dokumentieren Sie Commit, Artefakt-SHA-256, Plattform, Befehl und Ergebnis in validation.md.

    • [ ] Rust-Workspace-Tests, Formatierung und Clippy ohne Warnungen bestehen.
    • [ ] Der Abruf deckt Chinesisch/mehrere Suchbegriffe, Chunk-Offsets, den Ausschluss privater Inhalte/Zugangsdaten, Kollisionen sechsstelliger IDs, Cache-Invalidierung, Sperrung/ Widerruf/Quelländerungen während laufender Vorgänge und Offenlegungsbeschränkungen auf das Gerät ab. Prüfen Sie lokale EmbeddingGemma-Inferenz und Hashes der Modelldateien, Proxy-/Wiederholungsverhalten und die Validierung von Quellenangaben in Antworten. Dokumentieren Sie, ob echte Modellendpunkte von Kunden getestet wurden.
    • [ ] Flutter-Analyse, Formatierung und Widget-Tests bestehen.
    • [ ] E-Mail- und App-Signierungsjobs bestehen mit synthetischen Identitäten: S/MIME- und OpenPGP- Verifizierung/Entschlüsselung, Verifizierung signierter APKs sowie eine echte signierte AAB, die von der Release-Pipeline geprüft wurde. Prüfen Sie die Bindung zwischen Vorschau und Freigabe, Bereinigung bei Fehlern und Zugangsdaten-Arbeitsverzeichnisse, auf die nur der Eigentümer zugreifen kann, auf jeder Desktop-Plattform.
    • [ ] Validieren Sie unter macOS die iOS-Signierung mit einer temporären Apple-Identität, einem passenden Profil und Berechtigungen, einschließlich Framework-Reihenfolge, Keychain-Bereinigung und Geräteinstallation. Betrachten Sie Windows-Kompilierung nicht als Beleg für iOS-Signierung.
    • [ ] Regressionstests für das Ersetzen und Kopieren von Wiki-Geheimnissen bestehen über Core, CLI/IPC, FFI und Flutter hinweg. Prüfen Sie atomisches Fehlerverhalten, erhaltene Bearbeitungszuordnungen, Auflösung aktueller Werte, MCP-Verweigerung und Sperr-/Hintergrundverhalten mit synthetischen Daten.
    • [ ] Die tatsächliche Übergabe an die Zwischenablage wird auf jeder ausgelieferten Plattform geprüft, einschließlich Verfügbarkeit von Linux-Hilfsprogrammen und Übergabe an das mobile Betriebssystem. Tests mit simulierten Zwischenablagen allein erfüllen diese Prüfung nicht. Prüfen Sie Synchronisierung/Wiederherstellung von Geheimnisreferenzen mit aktualisierten Clients und dokumentieren Sie die Inkompatibilität älterer Clients in den Versionshinweisen.
    • [ ] Der native Android-Smoke-Test besteht nach dem Neubau der FFI; anschließend erfolgen ein gewöhnlicher APK-Neubau und die Prüfung mit scripts/verify-apk-native.py.
    • [ ] iOS-Xcode-/Simulator-Prüfungen bestehen mit der nativen Bibliothek und dem AppAuth-Plugin.
    • [ ] ARM64-Android-Hardware und ein physisches iOS-Gerät bestehen Prüfungen für Sperrung/Hintergrund, dauerhafte Speicherung im sicheren Speicher und Wiederherstellung.
    • [ ] Echte native/Desktop-Registrierungen für OneDrive und Google Drive bestehen Einwilligungs-, Aktualisierungs-, Abmelde-, Zwei-Geräte-Konvergenz-, Offline-Wiederholungs- und Widerrufstests. Verwenden Sie temporäre Cloud-Konten und synthetische Datensätze. Dokumentieren Sie Client-/Plattform- kombinationen; übertragen Sie ein iOS-OAuth-Ergebnis nicht auf Android.
    • [ ] Die Speicher-Benchmark-Ergebnisse erfüllen die vorgesehene unterstützte Bibliotheksgröße.
    • [ ] Ergebnisse unabhängiger Kryptografie-/Anwendungssicherheitsprüfungen und Penetrationstests sind behoben oder vom Verantwortlichen für die Veröffentlichung ausdrücklich akzeptiert.
    • [ ] Die Prüfung signierter Artefakte und eine unabhängige Sicherungs-/Wiederherstellungsübung bestehen.

    Der Validate-Workflow baut native Android- und iOS-Clients und führt deren Smoke-Tests aus. Build signed Android release ist ein manueller Workflow für die Umgebung release. Konfigurieren Sie ANDROID_KEYSTORE_BASE64, ANDROID_KEY_ALIAS, ANDROID_KEY_PASSWORD und ANDROID_STORE_PASSWORD als Umgebungsgeheimnisse. Er schlägt fehl, wenn Zugangsdaten fehlen, prüft die APK-Signatur/Kette nativer Bibliotheken und lädt APK und Prüfsumme als Workflow-Artefakt hoch. Er veröffentlicht in keinem Store. Prüfen Sie vor seiner Ausführung das Validate-Ergebnis des Quell-Commits.

    Committen Sie für Windows-Vorabveröffentlichungen den Quellcode und führen Sie pwsh -File scripts/package-windows.ps1 auf einem Windows-x86_64-MSVC-Host aus. Das Skript baut den Rust-Workspace neu und paketiert CLI, Tray, Relay, FFI-DLL/Importbibliothek, C-Header, README-/Sicherheits-/Lizenzdateien im Stammverzeichnis und jede versionierte Datei unter docs/, wobei die Verzeichnisstruktur erhalten bleibt. Das Archiv, BUILD-INFO.json (Quell-Commit und Hashes je Datei), memories.example.toml und SHA256SUMS werden nach dist/vVERSION/ geschrieben. Prüfen Sie Archivinhalt und Hashes, bevor Sie alle vier Dateien zur passenden GitHub Release hochladen. Bestehende Ausgabeverzeichnisse werden niemals überschrieben.

    Unter macOS baut bash scripts/package-macos.sh für die Host-Architektur und erstellt eine unsignierte Memories.app, ein CLI-/Relay-/FFI-Paket, die vollständige Dokumentation und Schriftlizenzen. Unter Linux baut bash scripts/build-linux.sh für das native GNU-Ziel x86_64/aarch64; --debug wählt einen Entwicklungsbuild. Aus einem sauberen, committeten Checkout erstellt bash scripts/package-linux.sh eine .tar.gz mit CLI/Relay/FFI, dem C- Header, versionierter Dokumentation und Lizenzen unter dist/vVERSION-linux-ARCH/, zusammen mit BUILD-INFO.json, memories.example.toml und SHA256SUMS. Prüfen Sie Hashes, Unix- Ausführungsberechtigungen und Laufzeitabhängigkeiten auf der vorgesehenen glibc-/OpenSSL- Distribution. Linux verwendet die WebUI und hat kein natives Tray-Paket.

    Der manuelle Workflow Build desktop packages führt Linux-/Windows-/macOS-Prüfungen aus und lädt diese Pakete als Workflow-Artefakte hoch; er veröffentlicht keine GitHub Release. Prüfen Sie vor der Weitergabe von Desktop-Builds Tray-Start/Menüaktionen/Beenden und WebUI-Darstellung auf dem ausgelieferten Betriebssystem sowie Token-/Origin-Zurückweisung, passiven Ablauf bei Inaktivität, das Leeren von Details bei Sperrung/Offline-Zustand und tatsächliche Daemon-Statusänderungen.

    Die iOS-Verteilung erfordert ein Apple-Team, Zertifikat/Profil und Provisionierungs- einstellungen unter macOS. Dieses Repository enthält keine Zugangsdaten oder Entwicklerkonten zur Auslieferung. Distributionsbuilds mit Cloud-Unterstützung benötigen außerdem die plattformspezifischen Client-IDs und registrierten Callback-Schemas aus cloud-authorization.md; der allgemeine CI-Build enthält keine OAuth-Client-Registrierung.