Memories

Memories / Documentation

Sur cette page

    Acceptation d'une version

    Exécutez chaque contrôle sur le commit et l'artefact destinés à être publiés. Les définitions CI et les résultats historiques ne prouvent pas qu'une nouvelle version a réussi les contrôles. Consignez le commit, le SHA-256 de l'artefact, la plateforme, la commande et le résultat dans validation.md.

    • [ ] Les tests de l'espace de travail Rust, le formatage et Clippy sans avertissement réussissent.
    • [ ] La recherche couvre le chinois et les mots-clés multiples, les décalages de fragments, l'exclusion des contenus privés et des identifiants, les collisions d'ID de six caractères, l'invalidation du cache, le verrouillage, la révocation et les changements de source pendant une opération, ainsi que les restrictions de divulgation limitées à l'appareil. Vérifiez l'inférence locale EmbeddingGemma et les hachages des fichiers du modèle, le comportement du proxy et des nouvelles tentatives, et la validation des citations des réponses. Indiquez si de véritables points de terminaison de modèles clients ont été testés.
    • [ ] L'analyse Flutter, le formatage et les tests de widgets réussissent.
    • [ ] Les tâches de messagerie et de signature d'applications réussissent avec des identités synthétiques : vérification/déchiffrement S/MIME et OpenPGP, vérification d'APK signés, et contrôle d'un véritable AAB signé par le pipeline de publication. Vérifiez la liaison aperçu/approbation, le nettoyage après échec et les espaces de travail d'identifiants réservés au propriétaire sur chaque plateforme de bureau.
    • [ ] Sur macOS, validez la signature iOS avec une identité Apple jetable, un profil et des autorisations correspondants, y compris l'ordre des frameworks, le nettoyage du trousseau et l'installation sur appareil. La compilation Windows ne prouve pas la signature iOS.
    • [ ] Les tests de régression de remplacement et de copie des secrets du wiki réussissent via core, CLI/IPC, FFI et Flutter. Vérifiez l'échec atomique, la préservation des correspondances d'édition, la résolution de la valeur actuelle, le refus MCP et la gestion du verrouillage et de l'arrière-plan avec des données synthétiques.
    • [ ] La livraison réelle dans le presse-papiers est vérifiée sur chaque plateforme distribuée, y compris la disponibilité des utilitaires Linux et la livraison par le système mobile. Les seuls tests simulés du presse-papiers ne satisfont pas ce contrôle. Vérifiez la synchronisation/restauration des références de secrets avec des clients à jour et documentez l'incompatibilité avec les anciens clients dans les notes de version.
    • [ ] Le test de fumée natif Android réussit après reconstruction de FFI, suivi d'une reconstruction normale de l'APK et d'une vérification par scripts/verify-apk-native.py.
    • [ ] Les contrôles iOS Xcode/simulateur réussissent avec la bibliothèque native et le plugin AppAuth.
    • [ ] Du matériel Android ARM64 et un appareil iOS physique réussissent les contrôles de verrouillage/arrière-plan, de persistance du stockage sécurisé et de restauration.
    • [ ] Les inscriptions natives/de bureau réelles OneDrive et Google Drive réussissent les tests de consentement, de renouvellement, de déconnexion, de convergence entre deux appareils, de nouvelle tentative hors ligne et de révocation. Utilisez des comptes cloud jetables et des enregistrements synthétiques. Consignez les combinaisons de clients et de plateformes ; n'extrapolez pas un résultat OAuth iOS à Android.
    • [ ] Les résultats du benchmark de stockage respectent la taille de bibliothèque prévue.
    • [ ] Les constats de la revue indépendante de cryptographie/sécurité applicative et du test d'intrusion sont résolus ou explicitement acceptés par le responsable de publication.
    • [ ] La vérification des artefacts signés et un exercice indépendant de sauvegarde/restauration réussissent.

    Le workflow Validate construit les clients natifs Android et iOS et exécute leurs tests de fumée. Build signed Android release est un workflow manuel ciblant l'environnement release. Configurez ANDROID_KEYSTORE_BASE64, ANDROID_KEY_ALIAS, ANDROID_KEY_PASSWORD et ANDROID_STORE_PASSWORD comme secrets d'environnement. Il échoue si les identifiants sont absents, vérifie la signature APK et la chaîne des bibliothèques natives, puis téléverse l'APK et sa somme de contrôle comme artefact du workflow. Il ne publie pas dans une boutique. Examinez le résultat Validate du commit source avant de l'exécuter.

    Pour les préversions Windows, commitez les sources et exécutez pwsh -File scripts/package-windows.ps1 depuis un hôte Windows x86_64 MSVC. Il reconstruit l'espace de travail Rust et empaquette la CLI, l'application de zone de notification, le relais, la DLL/bibliothèque d'importation FFI, l'en-tête C, les fichiers README/sécurité/licence racine et chaque fichier suivi sous docs/, en préservant l'arborescence. L'archive, BUILD-INFO.json (commit source et hachages de chaque fichier), memories.example.toml et SHA256SUMS sont écrits dans dist/vVERSION/. Vérifiez le contenu de l'archive et les hachages avant de téléverser les quatre fichiers vers la version GitHub correspondante. Les répertoires de sortie existants ne sont jamais écrasés.

    Sur macOS, bash scripts/package-macos.sh compile pour l'architecture hôte et crée une application Memories.app non signée, un paquet CLI/relais/FFI, la documentation complète et les licences des polices. Sur Linux, bash scripts/build-linux.sh compile la cible GNU native x86_64/aarch64 ; --debug sélectionne une compilation de développement. Depuis une copie propre et commitée, bash scripts/package-linux.sh crée un .tar.gz contenant CLI/relais/FFI, l'en-tête C, la documentation suivie et les licences sous dist/vVERSION-linux-ARCH/, avec BUILD-INFO.json, memories.example.toml et SHA256SUMS. Vérifiez les hachages, les permissions d'exécution Unix et les dépendances d'exécution sur la distribution glibc/OpenSSL visée. Linux utilise la WebUI et ne dispose pas de paquet natif de zone de notification.

    Le workflow manuel Build desktop packages exécute les contrôles Linux/Windows/macOS et téléverse ces paquets comme artefacts du workflow ; il ne publie pas de version GitHub. Avant de distribuer les versions de bureau, vérifiez le démarrage, les actions du menu et la fermeture de l'application de zone de notification, ainsi que le rendu de la WebUI sur le système distribué. Testez également le rejet du jeton/de l'Origin, l'expiration passive d'inactivité, l'effacement des détails au verrouillage ou hors ligne et les changements réels d'état du démon.

    La distribution iOS nécessite une équipe Apple, un certificat/profil et des paramètres de provisionnement sur macOS. Aucun identifiant ni compte développeur n'est fourni dans ce dépôt. Les versions distribuées avec le cloud activé nécessitent également les ID clients de plateforme et les schémas de rappel enregistrés décrits dans cloud-authorization.md ; la compilation CI générique ne contient pas d'inscription de client OAuth.