Registre de validation

Compilations locales de développement. Les résultats sont datés dans chaque section ; les empreintes des anciens artefacts ne s'appliquent qu'aux compilations auxquelles elles sont associées. Les exemples de commandes utilisent le nom actuel du projet ; les empreintes des artefacts historiques ne décrivent pas les binaires nouvellement nommés. Ces résultats décrivent les vérifications réellement exécutées ; la configuration CI ne constitue pas la preuve d'une exécution CI distante réussie ni d'un audit de sécurité indépendant.

Comptes SaaS et inscription configurable (2026-10-14)

La version 20261014-83aca4d86199 est déployée sur ldny. SHA-256 du binaire Linux : 83aca4d86199718587da2fe812471bffb6ea7aefd499c52ed53e6566a7dd4c73. Déploiement de l'interface des comptes : 908a7085.memories-ap4.pages.dev.

• cargo fmt --all --check, cargo clippy --workspace --all-targets --locked -- -D warnings et cargo test --workspace --locked ont réussi sous Windows. Les tests facultatifs existants dépendant de l'environnement conservent leur statut déclaré de tests ignorés.
• cargo build --workspace --release --locked a réussi sous Windows. La compilation Linux de production de memories-center a réussi avec le graphe de dépendances verrouillé et a été testée dans le conteneur Ubuntu compatible avec la production décrit ci-dessous.
• Tests du Center : 79 réussis, dont sept tests de comptes/configuration couvrant l'inscription par nom d'utilisateur, les identités canoniques, la vérification/expiration/réutilisation des courriels, les échecs de transport SMTP, la livraison réelle à un dispositif SMTP de test en boucle locale, le hachage des mots de passe, les limites du travail/des requêtes d'authentification, le refus des lectures/écritures entre comptes, les modifications et suppressions administratives, la déconnexion, la persistance après redémarrage et le refus par défaut des écritures des membres.
• Tests Node du client Web et du proxy API : 13 réussis. La génération de documentation a vérifié les liens et ancres locaux dans 32 pages HTML.
• Un véritable Chromium s'est inscrit/connecté à un Center isolé et a créé une mémoire. Les transitions du formulaire de courriel ont été vérifiées avec des réponses API simulées ; ces vérifications du navigateur n'ont envoyé aucun courriel. La livraison du courriel par le serveur a été vérifiée séparément avec le dispositif SMTP local de test, et non auprès d'un fournisseur externe.
• L'image de production exacte a réussi un test canari dans un conteneur ldny isolé avec deux comptes, des coffres distincts, le refus entre comptes, la déconnexion, la persistance après redémarrage et la connexion alors que l'inscription était fermée. Le conteneur canari et ses données synthétiques ont été supprimés. Les données de production n'ont pas servi à ce test.
• Le redémarrage de production a conservé l'identité du coffre et le jeton de membre du propriétaire existant via le domaine public. Le conteneur PostgreSQL et le service cloudflared existants sont restés en cours d'exécution. Les ressources intégrées de /app/ et les ressources publiques Pages correspondent. Les pages publiques pour ordinateur/mobile n'ont aucune erreur de console du navigateur et aucun débordement horizontal à 390px.
• La production sélectionne le mode courriel dans /etc/memories-center/auth.toml. SMTP a été configuré le 2026-10-14 avec Tencent enterprise mail et TLS implicite avec vérification du certificat sur le port 465. L'authentification auprès du fournisseur a réussi, le service a redémarré correctement et la configuration publique indique que l'inscription est activée. Une demande publique d'inscription a renvoyé 200 avec verification_required: true après l'envoi d'un courriel de vérification au fournisseur. La réception dans la boîte de réception et la soumission finale du code/mot de passe par l'utilisateur restent non vérifiées. Les mots de passe sont conservés uniquement dans une configuration protégée en dehors du dépôt.
• Sauvegarde cohérente protégée : /var/backups/memories-center/20261014-before-accounts-83aca4d86199/state-and-config.tar.gz. Preuves, correctif source et compte rendu de compilation : dist/saas-accounts-20261014/. Le correctif s'applique à la base propre enregistrée ; Git normalise les fins de ligne du texte.

SaaS hébergé sur ldny (2026-10-14, déploiement initial)

memories.ivjn.us sert désormais l'API du Center hébergé via un Cloudflare Worker et le Tunnel ldny existant. Le site statique, le client Web et la documentation indépendante restent sur Pages. ldny exécute la version Linux dans un conteneur Podman Ubuntu 24.04, avec les données chiffrées persistantes en dehors de l'image et la gestion du démarrage/redémarrage par systemd.

• Le point d'accès public /health renvoie ok ; /v1/public-key identifie memories-saas. Un accès anonyme à /v1/session renvoie 401, tandis qu'un membre/une autorisation avec périmètre renvoie la session autorisée. Les réponses API utilisent Cache-Control: no-store.
• Le contenu synthétique a survécu à un redémarrage du service. Un véritable Chromium a créé, modifié et rouvert une mémoire via https://memories.ivjn.us, puis l'a supprimée. La version finale du conteneur a réussi deux redémarrages systemd consécutifs avec un nouvel élément de test persistant. Un fichier binaire de 1 MiB téléversé/téléchargé via l'API publique avait un SHA-256 identique ; les autorisations de lecture seule ont refusé les écritures avec 403.
• Les vérifications du navigateur sur ordinateur et mobile à 390px n'ont révélé aucun débordement horizontal ni erreur de console. Les jetons/contenus étaient absents du stockage du navigateur. Le contenu de QA a été effacé et les autorisations temporaires révoquées. Un jeton de propriétaire existant fonctionnait toujours après la mise à niveau finale ; une sauvegarde protégée de l'état/de la configuration antérieurs a été conservée.
• Les 10 tests Node de l'API Web et du proxy en périphérie ont réussi. La compilation Linux de production et les tests de fumée locaux Linux d'authentification/persistance/ressources intégrées ont réussi.

Consultez deploy/README.md dans le dépôt pour l'organisation du service et le retour à la version précédente. Les secrets ont été générés sur le serveur et conservés en dehors du dépôt. Ces vérifications n'établissent pas une certification de sécurité indépendante ni l'inscription publique en libre-service. Les preuves locales se trouvent dans dist/saas-ldny-20261014/.

Memories Web (2026-10-14, déploiement initial de l'interface)

Ajout du client statique Center à /app/ et intégration des mêmes ressources dans memories-center. Il s'agit d'un client pour Center hébergé, pas d'un coffre hors ligne dans le navigateur. Ce déploiement initial de l'interface a précédé le déploiement SaaS enregistré ci-dessus.

• La séquence Rust complète a réussi : vérification du formatage, Clippy sur l'espace de travail/toutes les cibles avec interdiction des avertissements, tests de l'espace de travail avec dépendances verrouillées et compilation de production de l'espace de travail avec dépendances verrouillées. La suite Center comprend la validation des origines explicites et des tests de périmètre/authentification CORS.
• node --test scripts/tests/web-client.test.mjs : 6 réussis, couvrant la liaison des jetons à l'origine, les restrictions de redirection/cookies/cache, les mises à jour partielles, l'annulation et les réponses périmées, les courses lors d'échecs de connexion, les erreurs génériques et l'encodage binaire.
• Un véritable Chromium a connecté le site statique sur le port 8097 à un Center hébergé jetable sur le port 9297. La création/modification/réouverture de mémoire, la création/suppression de carte, le téléversement et le téléchargement de fichiers ont réussi. Un téléchargement binaire de 10,240 octets correspondait au SHA-256 source. Les autorisations de lecture désactivaient les modifications ; une autorisation d'écriture seule a créé une mémoire qui a été lue indépendamment avec l'autorisation du propriétaire, avec absence de la carte supprimée.
• Les dispositions de l'espace de travail sur ordinateur et mobile à 390px ont été inspectées. La déconnexion explicite a effacé le contenu visible et le champ du jeton ; le verrouillage après cinq minutes d'inactivité a également été observé. Ni localStorage ni sessionStorage ne contenaient de jetons ou de contenu.
• Le Center de production a servi les sept ressources intégrées à l'identique, octet par octet, des sources du site. Sa page /app/ s'est chargée sans erreur ni avertissement de console du navigateur, et les en-têtes CSP/de sécurité ont été vérifiés.

Seules des données synthétiques de coffre et des autorisations jetables ont été utilisées. Ces vérifications ne revendiquent ni connexion à un coffre de production, ni audit de sécurité indépendant, ni parité fonctionnelle avec les clients natifs. Les preuves sont conservées localement sous dist/site-update-7647166/output/playwright/ et dist/web-client-qa/.

Actualisation du client du site (2026-10-14)

Suivi du site : les cartes de téléchargement partagent désormais des lignes de grille pour les empreintes, les boutons principaux et les liens de métadonnées. La documentation autonome à /docs/ contient 29 pages générées avec navigation, liens de titres et menu repliable sur mobile. python scripts/build-website-docs.py vérifie les liens locaux et les cibles de fragments dans les 30 pages HTML. node --check a réussi pour les deux scripts du site. Les vérifications du navigateur ont couvert la page d'accueil, le portail de documentation, les guides anglais et chinois et la configuration à 390px, 900px et 1440px, sans débordement horizontal des pages ni erreur de console. Les boutons de téléchargement, les empreintes et les liens BUILD-INFO ont des positions verticales identiques sur les quatre cartes de bureau.

Base source : 7647166a6d97e59e9a466fec5ead287892b428af (main, synchronisée avec origin/main). Les paquets Windows et Linux utilisent cette source validée par commit. Android inclut également le correctif local de conservation du constructeur R8 décrit ci-dessous ; son BUILD-INFO.json enregistre source_dirty: true et le correctif source publié.

Les bases publiques sont https://r2.ivjn.us/memories/7647166/windows/, https://r2.ivjn.us/memories/7647166/linux/ et https://r2.ivjn.us/memories/7647166/android-cc5ac4b5/. Les trois paquets et leurs métadonnées publiées ont été téléchargés à nouveau et correspondaient aux empreintes SHA-256 locales. Le SHA-256 du SOURCE.patch Android est cc5ac4b57ced3bc87738d51da5ded84822627b5f05f8db024d323bde98dda4c2 ; git apply --check a réussi sur la copie de travail propre de base.

Validation effectuée :

• Rust 1.98.0 sous Windows : cargo fmt --all --check, cargo clippy --workspace --all-targets --locked -- -D warnings, cargo test --workspace --locked et cargo build --workspace --release --locked ont tous réussi. Les tests configurés comme ignorés restent ignorés ; les avertissements de compatibilité future des dépendances subsistent.
• Paquet Windows : 47 fichiers du manifeste et entrées d'archive vérifiés ; la commande --version de la CLI extraite a renvoyé memories 0.1.7, et --help du relais a réussi.
• Paquet Linux : compilé avec bash scripts/package-linux.sh dans une copie de travail GNU WSL propre (glibc 2.39, OpenSSL 3). Les 45 fichiers du manifeste, entrées d'archive et permissions d'exécution ont été vérifiés. Les commandes --version et file exec --help de la CLI extraite ont réussi ; ldd a résolu toutes les dépendances.
• 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 et flutter test ont réussi (126 tests).
• Les bibliothèques Rust FFI ARM64/x86_64 ont été recompilées et flutter test integration_test/native_smoke_test.dart -d emulator-5680 a été exécuté avec succès sur Android API 35 x86_64. L'ancienne assertion d'ID à huit caractères a été mise à jour pour correspondre au contrat du cœur : 6-16 caractères hexadécimaux, de longueur paire. L'APK de débogage ordinaire a ensuite été recompilé et ses bibliothèques natives vérifiées.
• L'APK de production a été compilé avec flutter build apk --release --target-platform android-arm64,android-x64 --build-number 8, aligné et signé au moyen de la configuration externe documentée dans AGENTS.md. apksigner verify a réussi avec le SHA-256 du certificat de production existant d637a37d5dd77aa5753722eccf53ab1b84baed2189e603cef9c34dbf354948f8. Les bibliothèques FFI sources, fusionnées, dépouillées de leurs symboles et empaquetées ont été vérifiées pour les deux ABI.
• Les tests réels de la version signée ont détecté un plantage R8 au démarrage : Room construit androidx.work.impl.WorkDatabase_Impl par réflexion, mais son constructeur public sans argument avait été supprimé. Une règle de conservation de périmètre étroit a été ajoutée, la compilation refaite, et deux démarrages à froid ainsi que l'entrée en mode Standalone ont été vérifiés sans exception fatale AndroidRuntime. Le candidat défaillant a été retiré avant le déploiement du site ; son URL publique d'APK renvoyait HTTP 404.
• La syntaxe JavaScript du site ainsi que les ressources HTML locales, les ID et les cibles de fragments ont passé les vérifications. Les tests locaux du navigateur à 1440px et 390px ont réussi le changement bilingue sans débordement horizontal ni erreur de console.

Le déploiement de production Cloudflare Pages a été effectué à https://09253fe4.memories-ap4.pages.dev pour le projet memories, branche main, avec des métadonnées de source modifiée. https://memories.ivjn.us/ a renvoyé HTTP 200 et correspondait au fichier local website/index.html octet par octet. Les 12 liens de téléchargement/métadonnées ont renvoyé HTTP 200, y compris les liens macOS conservés. Les en-têtes CSP, nosniff, de refus d'encadrement, de référent et permissions-policy étaient présents. Les vérifications du navigateur en production ont réussi à 1440px et 390px avec changement anglais/chinois, sans débordement horizontal et avec zéro erreur ou avertissement de console. Les captures d'écran se trouvent sous dist/site-update-7647166/output/playwright/live-*.png.

Les preuves locales et utilitaires se trouvent sous dist/site-update-7647166/ ; le paquet Windows se trouve sous dist/v0.1.7/. Les secrets de signature sont restés en dehors de la copie de travail. macOS conserve le téléchargement v0.1.3 existant : l'hôte macOS était hors ligne et GitHub Actions était bloqué par la limite de facturation/dépenses du compte. Aucune nouvelle compilation macOS ou iOS, exécution sur ARM64 physique, publication en boutique ni audit de sécurité indépendant n'est revendiquée. La validation Linux ci-dessus remplace la limitation Linux de l'ancienne base pour ce paquet.

Configuration de la CI native sans intervention (2026-10-01 ; planifiée, non exécutée)

La matrice de systèmes Rust dans .github/workflows/ci.yml planifie désormais des vérifications natives explicites après les tests ordinaires de l'espace de travail :

• Windows : cargo test -p memories --lib native_dpapi --locked exécute les tests existants d'aller-retour DPAPI pour l'utilisateur actuel et de refus après changement de liaison. Ils utilisent uniquement des tampons synthétiques en mémoire, libérés et remis à zéro par le garde de tampon natif ; le chemin fictif de garde des clés n'est jamais consulté.
• macOS : cargo test -p memories --lib unattended_backend::macos::tests::native_roundtrip_when_keychain_is_unlocked --locked -- --exact --ignored exécute uniquement le test natif d'aller-retour Keychain ignoré, pas les autres tests ignorés. Il crée une entrée synthétique sans synchronisation avec une liaison unique à un répertoire temporaire, puis supprime précisément cette entrée avant de vérifier le résultat de lecture ou d'affirmer l'égalité. Les erreurs de création, de lecture et de nettoyage font échouer le test ; une création échouée ne déclenche jamais la suppression d'une entrée préexistante.

L'exécuteur macOS doit fournir un trousseau utilisateur disponible et déverrouillé permettant la création/lecture/suppression sans interface. Aucun déverrouillage de trousseau, interface d'authentification, affaiblissement des ACL, changement global du trousseau ni injection de mot de passe n'est ajouté. Les trousseaux manquants ou verrouillés provoquent un échec plutôt qu'une omission silencieuse ou un mécanisme de repli. Si la suppression native échoue, le test échoue et son entrée synthétique peut rester sur l'exécuteur jetable. Des échecs antérieurs de formatage/lint/tests peuvent empêcher d'atteindre ces étapes.

Ces étapes sont configurées pour de futures exécutions CI sur push/pull request, et ne constituent pas des preuves d'exécution native. Aucun workflow n'a été déclenché et les tests natifs Windows et macOS n'ont pas été exécutés localement : cet environnement d'implémentation est Linux, sans hôtes natifs configurés. L'exécution native réelle et la validation sans interface dans les états verrouillé/nécessitant une approbation restent des conditions de publication ; la configuration CI seule ne les remplit pas.

Scripts de compilation et d'empaquetage Linux (2026-09-18)

Les nouveaux scripts shell Linux ont été validés dans Ubuntu sur WSL2 depuis une copie de travail Windows. bash -n a réussi pour les deux scripts. Des dépôts de test jetables avec commits et des outils de compilation simulés ont exercé la sélection production/débogage, la sélection explicite de cible native malgré un CARGO_BUILD_TARGET contradictoire, les chemins avec espaces, les répertoires cibles Cargo personnalisés, la disposition des archives x86_64/aarch64, les permissions d'exécution, les documents/licences suivis, les métadonnées du commit source et toutes les sommes de contrôle de fichiers/archives. Les systèmes incorrects, cibles non prises en charge, arguments invalides, OpenSSL manquant, compilations échouées, copies de travail modifiées et répertoires de paquet existants ont été rejetés comme prévu ; les archives existantes sont restées inchangées.

L'environnement WSL ne dispose d'aucune chaîne Rust/C ; cela valide donc le comportement des scripts avec des artefacts de test, pas la compilation Linux ni l'exécution native. Le workflow manuel de bureau mis à jour inclut l'installation des dépendances Linux, ShellCheck, les vérifications Rust, l'empaquetage, la vérification des sommes de contrôle et les commandes de fumée CLI/relais extraites ; ce workflow distant n'a pas été exécuté pour cette modification. ARM64 natif et la compatibilité des distributions/glibc/OpenSSL restent non vérifiés.

Windows v0.1.3 : récupération, modèles intégrés et ID à six caractères (2026-09-18)

L'étiquette v0.1.3 et le BUILD-INFO.json de production identifient la source et les fichiers empaquetés. Le moteur d'inférence fait partie de l'application ; les poids des modèles sont installés séparément comme fichiers de données vérifiés, sans être exécutés par une autre application.

• Régression de l'espace de travail : 158 réussis, zéro échec, 17 cas auxiliaires/dépendant d'outils/modèles intentionnellement ignorés. La suite finale de six tests de récupération a également réussi séparément, incluant une nouvelle régression de passage d'un document public à privé en cours de traitement, ajoutée après le démarrage des tests de l'espace de travail.
• EmbeddingGemma natif a fonctionné dans le processus avec les véritables fichiers de modèle Q4 épinglés. Une question chinoise a classé le document anglais pertinent sur les chiens avant un texte financier sans rapport, avec des vecteurs finis normalisés à 768 dimensions. Un second test réel CLI/démon a construit l'index vectoriel, retrouvé la correspondance sémantique et confirmé le refus après verrouillage/l'effacement du cache. Les deux tests facultatifs ont réussi après la désactivation explicite de la télémétrie ONNX avant la création de la session.
• La CLI finale optimisée de production Windows a aussi été exercée directement via de véritables IPC du démon : ID à six caractères, deux documents indexés, correspondance sémantique multilingue et refus après verrouillage ont réussi. Son rapport est target/rag-release-smoke.json ; aucune application externe d'embeddings n'a été utilisée.
• L'installation de modèles via la véritable CLI de production a réussi contre un miroir local jetable : un HTTP 429 injecté et une réponse de modèle interrompue ont été récupérés par nouvelles tentatives/plages (59 requêtes, 53 plages), et les sept fichiers de modèle correspondaient à leurs SHA-256 épinglés. Une nouvelle installation avec le miroir arrêté a réutilisé les fichiers vérifiés hors ligne. Aucun stockage chiffré n'a été initialisé par l'installation.
• Les dispositifs HTTP de test vérifient les charges utiles Gemini/compatibles, les dimensions demandées, les vérifications d'ordre/nombre/dimensions des embeddings, le reclassement appris, le rejet de citations, les nouvelles tentatives transitoires, les erreurs d'authentification sans nouvelle tentative, l'annulation et un véritable CONNECT de proxy HTTPS. Les corps d'échec et les échos directs des clés API sont supprimés.
• Les régressions recherche/RAG couvrent les termes chinois, les modes any/all/phrase, les décalages Unicode des fragments, la réutilisation/invalidation du cache vectoriel, les identifiants secrets/contenus privés/supprimés masqués, le verrouillage et la révocation d'autorisations, le refus entre coffres, le refus de divulgation distante des données réservées à l'appareil et les documents modifiés pendant le travail du modèle. L'ingestion/récupération CLI et MCP fonctionne sans modèle en mode BM25.
• Les ID à six caractères, l'extension des collisions à six/huit caractères, la compatibilité des anciens ID d'entrée à huit caractères et les projections de références typées réussissent avec les régressions existantes d'autorisation/stockage/FFI. Les ID canoniques stockés et les empreintes de sécurité sont inchangés.
• Le formatage, Clippy sur l'espace de travail/toutes les cibles avec -D warnings, les compilations optimisées et une compilation du cœur sans la fonctionnalité facultative d'embeddings natifs réussissent. Les avertissements existants de compatibilité future des dépendances et les avertissements informatifs de l'éditeur de liens natif subsistent.
• Les services Gemini/génération/reclassement réels du client n'ont pas été appelés ; la validation du protocole utilise des dispositifs HTTP synthétiques. L'exécution macOS/Linux et les compilations mobiles natives n'ont pas été exercées ici. La FFI mobile expose la récupération lexicale mais rejette les opérations fondées sur un modèle. Aucune interface Flutter n'a été modifiée.

Révision du modèle : 5090578d9565bb06545b4552f76e6bc2c93e4a66 de onnx-community/embeddinggemma-300m-ONNX. Les journaux sont target/rag-*.log et les enregistrements de téléchargement/miroir se trouvent sous target/. Seuls des stockages, documents et identifiants secrets synthétiques ont été utilisés.

Windows v0.1.2 : état et configuration du bureau (2026-09-18)

L'étiquette v0.1.2 identifie cette source. Le BUILD-INFO.json de production associe le commit exact et chaque fichier empaqueté ; SHA256SUMS couvre également l'exemple de configuration autonome. L'archive Windows comprend l'exécutable de la zone de notification, la WebUI intégrée, toute la documentation suivie, l'exemple TOML et les licences des polices intégrées.

• cargo test --workspace --locked -- --test-threads=2 : 144 réussis, zéro échec, 14 cas auxiliaires de sous-processus/d'outils externes intentionnellement ignorés. Une régression renforcée de transmission de configuration/WebUI réelle a également réussi séparément sur la source finale (deux tests d'intégration de bureau).
• Le formatage, Clippy sur l'espace de travail/toutes les cibles avec -D warnings et les compilations optimisées de l'espace de travail ont réussi sur Rust 1.98.1 MSVC. Les avertissements existants de compatibilité future des dépendances et les avertissements informatifs de l'éditeur de liens FFI subsistent.
• Les régressions couvrent le rejet des capacités/Host/Origin/fetch-site, l'absence de routes de modification ou d'IPC générique, la rotation des jetons, l'arrêt avec connexions HTTP partielles, l'expiration passive après inactivité, les détails verrouillés masqués et le refus MCP. L'intégration réelle démon/WebUI couvre la configuration, les compteurs déverrouillés, le verrouillage et la déconnexion.
• Les tests de configuration couvrent la priorité CLI/environnement/fichier, le stockage relatif, l'inspection sans stockage, la transmission explicite de configuration aux sondes, la langue enregistrée dans le répertoire personnel sélectionné, les valeurs par défaut du relais, les valeurs mal formées, les erreurs expurgées et la préservation des fichiers de configuration existants.
• Les véritables processus CLI/zone de notification de production Windows ont démarré avec un fichier TOML jetable et un stockage synthétique. Le navigateur a vérifié les états verrouillé/déverrouillé et trois bibliothèques synthétiques, les cinq langues et les dispositions bureau/390 pixels sans débordement horizontal ni erreur du navigateur. Le processus de notification est resté réactif sans erreur au démarrage. Les clics de menu natifs n'ont pas été vérifiés car la surface d'automatisation n'exposait pas de fenêtre de barre des tâches/notification.
• cargo package --list inclut les ressources/polices intégrées, le modèle de configuration et les sources du lanceur. Les vérifications de syntaxe d'empaquetage shell/Python intégré macOS ont réussi. La compilation macOS, l'exécution dans la barre de menus, la signature/notarisation et les vérifications d'exécution Linux n'étaient pas disponibles sur cet hôte Windows.
• Aucun fichier mobile ni code Flutter n'a changé ; les exécutions Flutter/appareil natif et les cas facultatifs d'outils cryptographiques externes n'ont pas été répétés pour cette version.

Les journaux sont target/desktop-config-*.log et target/config-tests.log. Le workflow manuel Build desktop packages fournit des tâches d'empaquetage Windows/macOS ; une définition de workflow n'établit pas une compilation macOS réussie.

Windows v0.1.1 : documentation et alias d'ID de mot de passe (2026-09-18)

L'étiquette v0.1.1 identifie la source. Cette préversion Windows uniquement inclut tous les fichiers suivis de docs/ avec leur arborescence intacte ; son BUILD-INFO.json enregistre le commit source et le SHA-256 de chaque fichier empaqueté, et SHA256SUMS couvre l'archive et le manifeste de compilation.

• cargo test -p memories --locked --test crypto_jobs --test localization : sept réussis, zéro échec ; trois tests d'outils externes intentionnellement ignorés. La couverture de régression confirme que --password_id, --password et --password-id produisent des plans/empreintes d'approbation identiques ; un changement d'ID d'identifiant secret change l'approbation. L'aide en cinq langues présente les alias.
• cargo fmt --all --check, Clippy sur l'espace de travail/toutes les cibles avec -D warnings et cargo build --workspace --release --locked ont réussi sur Rust 1.98.1 MSVC. Les avis existants de compatibilité future des dépendances et de l'éditeur de liens FFI subsistent.
• Les tests de fumée de version CLI/relais de production et d'aide crypto ont réussi.
• Les résultats complets de l'espace de travail, des outils externes et de Flutter ci-dessous s'appliquent à v0.1.0 ; ces suites plus larges n'ont pas été répétées pour cette mise à jour d'alias CLI/documentation. Aucun artefact mobile n'a été recompilé ; la version de l'application Flutter est inchangée.
• La commande d'empaquetage reproductible est pwsh -File scripts/package-windows.ps1. Les journaux de cette exécution se trouvent sous target/release-0.1.1-*.log.

Préversion Windows v0.1.0 (2026-09-18)

Compilée localement sous Windows x86_64 avec Rust 1.98.1 MSVC et Flutter 3.44.2. L'étiquette v0.1.0 identifie la source ; le BUILD-INFO.json de production enregistre son commit complet et SHA256SUMS couvre les ressources téléchargeables.

• cargo test --workspace --locked -- --test-threads=2 : 131 réussis, zéro échec, 14 tests intentionnellement ignorés. Le bureau était actif et déverrouillé ; les deux tests IPC auparavant bloqués par le verrouillage de l'écran ont réussi sans exclusion.
• Les trois tests facultatifs d'interopérabilité crypto ont réussi séparément avec des identités synthétiques : S/MIME, OpenPGP et signature Android au format APK/AAB.
• Le formatage Rust, Clippy sur l'espace de travail/toutes les cibles avec -D warnings et cargo build --workspace --release --locked ont réussi. Les avis existants de compatibilité future des dépendances subsistent.
• L'analyse Flutter, le formatage Dart et les 36 tests Flutter ont réussi.
• La version/l'aide crypto de la CLI de production, l'aide du relais et un véritable test de fumée de DLL de production (initialiser, verrouiller, déverrouiller, tout verrouiller, fermer) ont réussi avec une base jetable.
• GitHub Actions n'a pas pu démarrer car GitHub a signalé une restriction de paiement ou de plafond de dépenses du compte. Il s'agit de résultats locaux, pas de résultats CI distants.
• Les ressources sont des binaires Windows de développement non signés. La configuration/le téléchargement Android NDK n'a pas terminé ; les artefacts Android/iOS et les tests sur appareil natif n'ont pas été produits pendant cette exécution. Les compilations Linux/macOS et l'acceptation de la version de production restent ouvertes.

Les journaux se trouvent sous target/release-20260918-*.log.

Cryptographie du courrier et signature d'applications (2026-09-17)

• Trois tests facultatifs d'interopérabilité réussissent uniquement avec des identités générées : signature/vérification S/MIME et chiffrement/déchiffrement PKCS#12 ; signature/vérification détachée OpenPGP et chiffrement/déchiffrement ; alignement/signature/vérification Android APK et signature/vérification JAR au format AAB. L'APK de test possède un véritable manifeste Android binaire ; le test AAB est un conteneur JAR synthétique, pas un App Bundle déployable. Aucun compte, identité ni application réel n'a été utilisé.
• Outils de l'hôte : Git for Windows OpenSSL 3.5.6, MSYS GnuPG 2.4.9, Adoptium JDK 17, Android Build Tools 35.0.0 et le JAR de la plateforme Android 36. Les tests GPG utilisent --msys-gpg et des trousseaux jetables. Exécutez les tests facultatifs avec les chemins d'outils MEMORIES_TEST_* nommés dans crates/cli/tests/crypto_jobs.rs et cargo test -p memories --locked --test crypto_jobs -- --ignored --test-threads=1.
• Les régressions du cœur couvrent l'élévation locale, le refus MCP, les approbations altérées, les entrées/outils modifiés, les sorties existantes, les audits/résultats sans secrets, le nettoyage temporaire des identifiants secrets, l'échec d'exécution d'outils et les outils qui réussissent sans produire de sortie. L'aide CLI en cinq langues et le refus iOS hors macOS sont aussi testés.
• En excluant les deux cas IPC dépendant du verrouillage d'écran ci-dessous, l'exécution de l'espace de travail réussit 129 tests, avec zéro échec et 14 tests intentionnellement ignorés (auxiliaires de sous-processus et les trois tests d'outils exécutés séparément). La commande est 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 sur l'espace de travail/toutes les cibles avec -D warnings, le formatage Rust, la vérification des espaces du diff et la vérification quick_validate.py de la compétence mise à jour réussissent.
• L'exécution complète de l'espace de travail a rencontré deux échecs existants de démon/IPC réels alors que la session Windows était déconnectée/verrouillée (query user indiquait Disc, avec LogonUI dans cette session). Le hook de verrouillage d'écran du démon a révoqué les sessions synthétiques, produisant LOCKED ou des erreurs de sessions distantes supprimées. La répétition de ces tests en série a montré le même comportement de verrouillage. Ils nécessitent un bureau actif et déverrouillé ; la protection de verrouillage n'a pas été désactivée pour les tests.
• La signature iOS est implémentée mais son exécution n'a pas été validée sur macOS. Aucun appareil Android n'est connecté et aucun NDK n'est installé ici ; les bibliothèques mobiles natives, APK et artefacts iOS n'ont pas été recompilés. La FFI mobile continue de refuser les tâches de processus de bureau. L'installation physique, l'acceptation de provisionnement Apple, l'intégration des clients mail PGP/MIME et la publication en boutique ne sont pas revendiquées.

Injection de compétence dans les clients IA (2026-09-17)

• Avant le push, l'instantané indexé ne contenant que la compétence a été exporté vers un répertoire isolé et a réussi cargo test -p memories --locked --bin memories --test skill_injection --test localization : 25 réussis, zéro échec, quatre auxiliaires de sous-processus intentionnellement ignorés. Le formatage y réussit aussi.
• Validation complète de la copie de travail, incluant les modifications wiki/presse-papiers préexistantes : cargo test --workspace --locked -- --test-threads=2 : 127 réussis, zéro échec, dix auxiliaires de sous-processus intentionnellement ignorés et invoqués par les scénarios parents. Les régressions existantes d'autorisation, MCP, stockage, synchronisation, FFI et relais réussissent avec les nouveaux tests d'installation.
• Windows : neuf nouvelles régressions réussissent (trois tests unitaires et six tests d'intégration CLI). Elles couvrent les répertoires utilisateur/projet, les remplacements de configuration, les cibles dupliquées, les chemins de remplacement partagés, la simulation, l'idempotence, le remplacement explicite, la détection préalable des conflits, les entrées invalides, la préservation des fichiers voisins et l'aide en cinq langues. Les tests utilisent des répertoires jetables sans démarrer de démon ni initialiser de stockage Memories.
• Une vérification séparée de jonction Windows confirme que --force rejette un répertoire de compétence lié avant d'écrire les autres cibles et préserve son fichier d'origine. La régression de lien symbolique Unix est incluse mais n'a pas été exécutée sur cet hôte.
• cargo build --workspace --locked, cargo fmt --all --check, cargo clippy --workspace --all-targets --locked -- -D warnings et git diff --check réussissent. Les avertissements existants de compatibilité future des dépendances Rust et les avertissements informatifs de l'éditeur de liens FFI subsistent.
• La vérification quick_validate.py de skill-creator réussit. cargo package -p memories --list --allow-dirty --locked confirme que le SKILL.md intégré est distribué avec le paquet CLI. L'installation ne nécessite aucun accès réseau.
• Les chemins de découverte ont été vérifiés avec la documentation actuelle de Codex, OpenCode et Claude Code. La découverte/le comportement des modèles dans les clients réels, l'exécution Linux/macOS, Claude Desktop/Cowork et les téléversements de compétences dans le cloud n'ont pas été exercés. Aucun répertoire personnel de compétences ni configuration de client n'a été modifié pendant la validation.

Références secrètes wiki et presse-papiers (2026-09-17)

• Espace de travail Rust Windows : 118 réussis, zéro échec, dix auxiliaires de sous-processus intentionnellement ignorés et invoqués par les scénarios parents. La compilation de l'espace de travail, le formatage Rust et les vérifications des espaces du diff réussissent. Les chemins CLI, IPC et FFI mis à jour ont aussi été vérifiés dans des exécutions ciblées après leurs modifications finales.
• Quatre régressions fonctionnelles du cœur réussissent : remplacement exact, projections sûres, élévation locale/isolation MCP, rejet des métadonnées (y compris le texte échappé), copies de cartes protégées, rejet binaire/NUL, synchronisation, persistance et restauration indépendante de sauvegarde. Une exécution ciblée supplémentaire vérifie le retour arrière atomique lorsque le remplacement agrandit un document au-delà de la limite de taille du corps, après la préparation de l'identifiant secret. Le contenu historique signé reste intentionnellement inchangé.
• La suite IPC réelle CLI/démon réussit (trois tests et quatre auxiliaires de sous-processus explicitement invoqués), incluant le remplacement, les lectures masquées et la livraison de copie autorisée. La régression FFI réussit avec les mêmes opérations JSON et refuse les copies après verrouillage natif. Tous les dispositifs utilisent des secrets synthétiques et des stockages jetables ; aucun stockage installé ni presse-papiers utilisateur n'a été utilisé.
• Flutter : 36 tests réussis, dont cinq nouveaux cas pour la saisie de remplacement masquée, l'élévation avant écriture dans le presse-papiers, l'abandon des réponses tardives après verrouillage en arrière-plan, les échecs de copie et la préservation des références pendant la modification. La livraison au presse-papiers utilise un canal de plateforme simulé. L'analyse Flutter, le formatage Dart et Clippy sur l'espace de travail/toutes les cibles avec -D warnings réussissent.
• Les appels natifs au presse-papiers Windows compilent mais n'ont pas été exercés sur le presse-papiers interactif. Les utilitaires de presse-papiers Linux/macOS et la livraison au presse-papiers du système mobile n'ont pas été exécutés. Aucun appareil Android n'était connecté et aucun NDK n'était installé dans le SDK configuré ; les bibliothèques/APK Android et les artefacts iOS n'ont pas été recompilés.
• Journaux : 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 et target/wiki-build.log.

Préférences de langue enregistrées (2026-09-17)

• Tests CLI : 19 réussis, huit auxiliaires de sous-processus intentionnellement ignorés. Les tests de persistance lancent des processus CLI séparés avec des répertoires personnels jetables et vérifient l'enregistrement/le remplacement d'une préférence, la sélection au démarrage et dans l'aide, l'isolation par répertoire personnel, les remplacements temporaires, l'effacement du paramètre, les paramètres mal formés et le nettoyage après échec d'écriture.
• Tests Flutter : 31 réussis. De nouvelles régressions vérifient que les changements de locale système en direct mettent à jour l'interface et le repli des polices sans enregistrer de préférence. Les choix enregistrés restent fixes ; le rétablissement de la valeur système par défaut persiste après redémarrage.
• L'analyse Flutter, Clippy sur l'espace de travail/toutes les cibles avec -D warnings, le formatage Rust/Dart et les vérifications des espaces du diff réussissent. Les appareils natifs n'ont pas été exercés.
• Journaux : target/i18n/persistence-rust.txt et target/i18n/persistence-flutter.txt.

Client et CLI en cinq langues (2026-09-17)

Hôte : Windows x86_64, Rust 1.98.1 MSVC, Flutter 3.44.2 / Dart 3.12.2.

• Tests de l'espace de travail Rust : 112 réussis, dix auxiliaires de sous-processus intentionnellement ignorés. Les tests de localisation CLI réussissent également sur les modifications finales de la CLI.
• Tests de widgets/unitaires Flutter : 29 réussis, couvrant cinq langues système, le repli vers l'anglais, la sélection persistante de langue, la préservation de la session déverrouillée, les dialogues de largeur téléphone, les nombres au pluriel et le masquage des aperçus protégés.
• L'analyse Flutter, le formatage Rust/Dart, Clippy sur l'espace de travail/toutes les cibles avec -D warnings et les vérifications des espaces du diff réussissent. Les avis existants de compatibilité future des dépendances Rust subsistent.
• L'aide CLI, l'aide imbriquée, la priorité des locales et les erreurs non interactives localisées ont été exercées via le véritable binaire. Les champs JSON et codes d'erreur restent stables. Les captures de widgets ont été rendues à 390 x 844 avec des polices chargées pour les tests.

Les journaux locaux se trouvent dans target/i18n/. Le proxy HTTP de l'hôte a été exclu des connexions de test en boucle locale de Flutter. Aucun appareil Android/iOS, sélecteur de fichiers natif, fournisseur OAuth réel ni exécution Linux/macOS n'a été exercé pour cette modification de localisation.

Suivi de la récupération cloud et de la révocation (2026-09-17)

Hôte : Windows x86_64, Rust 1.98.1 MSVC. Les dispositifs de régression utilisent des données synthétiques, des bases chiffrées temporaires et uniquement HTTP en boucle locale.

• cargo test --workspace --locked -j 2 --no-fail-fast -- --test-threads=2 : 106 réussis, dix auxiliaires de sous-processus intentionnellement ignorés. Cela comprend les 24 tests d'intégration de synchronisation cloud/HTTP.
• cargo fmt --all --check et Clippy sur l'espace de travail/toutes les cibles avec -D warnings réussissent. Les avis existants de compatibilité future des dépendances subsistent.

La suite de régression couvre les réponses de téléchargement endommagées suivies de nouvelles tentatives saines, les objets rejetés restant distincts des importations réussies et une nouvelle analyse unique des anciens reçus. Elle vérifie aussi les téléchargements de dépendances avec une boîte de réception pleine, l'éviction des tampons d'enveloppes non référencées et le maintien des curseurs de répertoire sur une page partiellement admise.

Les tests de révocation couvrent les données en attente qui ne doivent jamais être envoyées ainsi qu'un téléversement déjà en cours : ce dernier peut terminer, mais la requête suivante est empêchée et son accusé de réception périmé est rejeté. Le dispositif Google Drive accepte les noms dupliqués et ne rejette que les ID de fichiers dupliqués. Son test de redémarrage interrompt le worker après l'acceptation d'un fichier par le serveur, vérifie que l'ID était déjà enregistré localement, puis vérifie qu'une nouvelle tentative crée exactement une enveloppe et un descripteur.

Le dispositif HTTP place explicitement les sockets acceptés en mode bloquant sous Windows ; sinon ils peuvent hériter du mode non bloquant du socket d'écoute et réinitialiser les connexions avant l'arrivée des octets de requête. Le dispositif en mémoire masque désormais les objets à la fois dans les listes et les téléchargements directs lorsqu'il simule une publication incomplète.

Aucun compte cloud réel ni appareil natif Android/iOS n'a été utilisé pour ce suivi. Les limites d'acceptation des plateformes et des versions enregistrées ci-dessous s'appliquent toujours.

Suivi de la fiabilité et du cloud mobile (2026-09-17)

Hôte : Windows x86_64, Rust 1.98.1 MSVC, Flutter 3.44.2 / Dart 3.12.2. Des secrets synthétiques et des bases jetables ont été utilisés partout.

• Les tests de l'espace de travail Rust réussissent, incluant la régression de client bloqué/verrouillage du démon réel. Les tests ciblés vérifient en outre qu'une requête HTTP cloud bloquée permet le verrouillage, que les exécutions simultanées de fournisseurs sont rejetées et qu'un accusé de réception tardif ne peut pas restaurer une session invalidée.
• Les régressions cloud couvrent les redirections de téléchargement OneDrive normales sans transmission des jetons Bearer, les boucles de redirection/destinations dangereuses, la mise en attente et la reconnexion par fournisseur, la réduction de la file terminée au-delà des anciennes limites 256/4096 et les nouvelles tentatives d'objets temporairement manquants après temporisation. Les destinataires révoqués ne bloquent plus la préparation pour les appareils actifs ni ne maintiennent un coffre modifié indéfiniment. Le dispositif HTTP reste désormais actif jusqu'à ce que son propriétaire l'arrête, au lieu d'expirer après 30 secondes.
• Le test FFI Windows vérifie les verrouillages d'arrière-plan en attente sur les handles occupés et inactifs et la distribution via le worker cloud natif. La validation OAuth native rejette les callbacks dangereux et PKCE mal formé avant les entrées/sorties réseau.
• Le formatage Rust et Clippy sur l'espace de travail/toutes les cibles avec -D warnings réussissent. Les avis existants de compatibilité future de russh/proc-macro-error2 subsistent.
• L'analyse Flutter et les 16 tests de widgets réussissent, y compris l'état du compte et le verrouillage manuel pendant une requête de synchronisation. Les jetons Rust d'accès/actualisation ne sont jamais renvoyés à Dart ; AppAuth fournit le code/vérificateur d'autorisation.
• Le benchmark de stockage de production s'exécute avec 10, 100 et 1000 enregistrements synthétiques. Les résultats et définitions des métriques figurent dans Performances. L'ajout à l'audit ne dérive plus la même clé publique d'appareil pour chaque entrée antérieure.
• Le YAML des workflows, le Python intégré de configuration de signature, l'échappement Unicode des propriétés Java, les liens/blocs Markdown et les espaces du diff sont vérifiés localement.

L'installation des SDK/NDK/émulateur Android a été tentée, mais les transferts des grandes archives officielles étaient trop lents pour terminer pendant cette exécution. Aucun résultat APK/appareil natif Android n'est revendiqué pour cette modification. Les compilations iOS nécessitent macOS et n'ont pas été exécutées. Les nouvelles tâches CI natives et le workflow manuel de signature Android n'ont pas été exécutés à distance. Ce sont des vérifications configurées, pas des artefacts de compilation vérifiés.

Aucun client OAuth natif enregistré, consentement cloud réel, distribution signée, exécution sur appareil physique ni revue de sécurité indépendante n'a été effectué. La prise en charge des redirections natives Google doit être validée séparément pour Android et iOS avec l'inscription choisie. Consultez la Liste de contrôle de publication pour les critères d'acceptation. Les binaires memories installés et les véritables coffres utilisateurs n'ont pas été remplacés.

Nommage du projet pour la première version (2026-09-17)

Le projet, le dépôt, la CLI, les paquets Rust et Dart, les symboles et l'en-tête FFI, les identifiants Android/iOS, les noms de stockage, les variables d'environnement et les domaines cryptographiques utilisent désormais uniformément memories. Cette première version ne dispose d'aucun alias de nom antérieur ni de voie de migration. Le dépôt est https://github.com/mbcc2006/memories.

Hôte : 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 réussis, dix auxiliaires de sous-processus intentionnellement ignorés.
• cargo fmt --all --check et Clippy sur l'espace de travail/toutes les cibles avec -D warnings : réussis.
• cargo build --workspace --release --locked -j 2 : réussi ; la version CLI et l'aide du relais indiquent toutes deux le nouveau nom.
• Six tests de fumée CLI/démon/FFI de production ont réussi avec une bibliothèque jetable : initialisation/écriture/sauvegarde natives, déverrouillage/lecture du démon, sélection par MEMORIES_HOME, lecture et verrouillage/déverrouillage CLI, restauration native de sauvegarde et export memories_lock_all verrouillant les handles natifs actifs.
• Formatage Dart et flutter analyze : réussis. Tests de widgets Flutter : 14 réussis. La première exécution des widgets n'a pas pu se connecter à l'exécuteur local de tests à cause du proxy HTTP de l'hôte ; la nouvelle exécution sans variables de proxy dans ce processus et avec la boucle locale dans NO_PROXY a réussi.

Les preuves locales se trouvent dans 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 et target/rename-flutter-tests.log. Le rapport E2E associe son résultat à l'empreinte de la CLI. Les compilations APK Android/iOS et les tests d'intégration sur appareil natif n'ont pas été exécutés pour ce renommage. Les résultats E2E de proxy sur services réels dans la section suivante décrivent leur compilation antérieure ; cette section enregistre les tests de fumée locaux de la nouvelle version.

Proxys SSH/bases de données et E2E de production (2026-09-16)

Hôte : Windows x86_64, Rust 1.98.1 MSVC. La CLI/le démon de production ont été exercés avec des serveurs jetables OpenSSH 8.9p1, PostgreSQL 14.24, MySQL 8.0.46 et Redis 6.0.16 dans Ubuntu 22.04 WSL. Les paquets des serveurs ont été extraits dans un répertoire temporaire privé, avec des données, certificats et comptes synthétiques indépendants ; aucun service système n'a été installé. Le démon de test utilisait un --home jetable. Tous les serveurs de test ont été arrêtés et leurs données/clés privées supprimées ensuite.

• Régression de l'espace de travail : 88 réussis, dix auxiliaires de sous-processus intentionnellement ignorés. Commande : cargo test --workspace --locked -j 1 -- --test-threads=1.
• Les corrections ultérieures des ID courts ont réussi les neuf tests distants et le scénario IPC du démon réel. Le correctif final d'arrêt a réussi les quatre tests de proxy, les deux scénarios IPC et une régression supplémentaire d'arrêt immédiat/verrouillage sans attente/join d'arrêt dans le client de test. Ces exécutions ciblées suivent l'exécution complète de l'espace de travail.
• Clippy final sur l'espace de travail/toutes les cibles avec -D warnings, le formatage Rust et les vérifications des espaces du diff ont réussi. Les avis existants de compatibilité future des dépendances russh et proc-macro-error2 subsistent ; aucune erreur de lint n'a été supprimée.
• cargo build --workspace --release --locked -j 2 a réussi. Les commandes de version/aide de la CLI recompilée et d'aide du relais ont été exécutées avec succès. Le démon installé et les données utilisateur n'ont pas été remplacés.
• 11 vérifications E2E sur services réels ont réussi avec scripts/test-proxy-e2e.py sur le binaire de production recompilé. Les clients OpenSSH et SFTP, psycopg2, PyMySQL et redis-py se sont connectés aux proxys en boucle locale créés par le démon sans secrets des serveurs amont.

La couverture E2E comprend l'importation d'identifiants secrets par ID court et le refus de lecture des secrets ; le rejet des incompatibilités de clé d'hôte SSH ; la transmission de stdout, stderr et du statut de sortie ; un téléversement/téléchargement SFTP ; le refus TLS PostgreSQL non approuvé ; PostgreSQL SCRAM, TLS vérifié, Unicode et retour arrière de transaction ; MySQL caching-SHA-256, TLS vérifié et Unicode à quatre octets ; Redis AUTH sur TLS ; l'isolation de l'élévation MCP ; l'arrêt explicite sans interruption des autres proxys ; et le verrouillage fermant tous les sockets d'écoute ainsi que les connexions SSH/bases de données déjà établies.

La première exécution E2E a révélé que proxy stop revenait alors que la boucle d'acceptation pouvait encore transmettre des requêtes pendant jusqu'à 200 ms. Le service détient désormais le worker de proxy et attend sa fin avant d'accuser réception de l'arrêt/du verrouillage. La nouvelle exécution E2E finale vérifie la déconnexion immédiatement après la réponse et réussit.

Preuves locales : 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 et target/proxy-e2e/results/report.json. Le rapport associe le résultat E2E au SHA-256 de la CLI ci-dessous. Le script réutilisable nécessite des dispositifs jetables provisionnés à l'extérieur, comme décrit dans la documentation de son module ; il n'installe pas de serveurs.

Les artefacts Android/iOS et les tests d'exécution native n'ont pas été recompilés ni exécutés pour cette modification de proxy de bureau. Aucun SSH/base de données de production ni compte cloud réel n'a été utilisé.

Synchronisation d'objets cloud (2026-09-16)

Ajout d'un exécuteur d'objets immuables indépendant des fournisseurs avec reçus durables de boîtes d'envoi/réception. La couverture se trouve dans les tests unitaires de crates/core/src/sync.rs et crates/core/tests/cloud_sync.rs :

• Les octets exacts des enveloppes persistent après réouverture du processus ; un put échoué réessaie le même ID d'objet sans rechiffrement.
• Un put dupliqué télécharge et vérifie l'objet existant avant de marquer la tâche comme téléversée.
• Un descripteur listé avant son enveloppe reste en attente ; révéler l'enveloppe et réordonner/dupliquer la liste n'importe toujours qu'une fois.
• Un téléchargement corrompu est enregistré comme corrupt et ne fusionne pas l'état du coffre.
• Le verrouillage et la déconnexion incrémentent la session de synchronisation afin qu'un CloudSyncAck tardif ne puisse pas importer ; les tâches incomplètes de boîte d'envoi restent dans l'état chiffré après déverrouillage jusqu'à leur annulation par la déconnexion.
• Deux appareils appairés échangent des modifications simultanées via MemoryTransport.
• Les coffres locaux uniquement et les appelants MCP ne peuvent pas mettre de travail en attente ni l'inspecter. Les sauvegardes et bibliothèques restaurées ont un cloud_sync vide et aucun compte cloud.

Des sessions SSH/FTP/TCP détenues par le démon avec proposition/approbation/exécution par instruction ont été ajoutées (crates/core/src/remote.rs, crates/core/tests/remote.rs). Les sessions MySQL, Redis et PostgreSQL conservent leur état sur la connexion active et activent TLS par défaut (vérification du nom d'hôte ; identifiant secret CA PEM facultatif). --no-tls est explicite. Les négociations TLS de bases de données réelles n'ont pas été exécutées. La génération de clés SSH/TLS conserve les clés privées dans le stockage des identifiants secrets ; les tests affirment que les réponses generate/public ne contiennent aucun PEM de clé privée. Les proxys SSH/Redis en boucle locale injectent les identifiants secrets stockés pour qu'un client local puisse se connecter sans le secret ; le verrouillage active le drapeau d'arrêt du proxy. Aucun compte réel n'a été utilisé.

L'actualisation des jetons, les adaptateurs OneDrive/Google Drive, CloudSyncRun du démon et memories cloud sync ont été ajoutés. La couverture se trouve dans les tests d'actualisation de cloud.rs et les dispositifs en boucle locale de crates/core/tests/cloud_drive.rs. Les comptes Microsoft/Google réels n'ont pas été autorisés. Aucune interface mobile de connexion/synchronisation n'a été ajoutée.

Vérification locale le 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 réussis, deux auxiliaires de sous-processus intentionnellement ignorés.
• cargo clippy -p memories-core --all-targets --locked -- -D warnings : réussi.
• cargo fmt --all : réussi.

Revue du dépôt (2026-09-09)

• Espace de travail Rust Windows : 51 réussis, zéro échec. Dix auxiliaires de sous-processus intentionnellement ignorés sont lancés explicitement par leurs tests parents. Commande : cargo test --workspace --locked -j 1 -- --test-threads=1.
• Les tests d'initialisation tuent un processus après la préparation et avant la publication, puis recréent/déverrouillent le stockage avec succès. Les destinations existantes, y compris un fichier apparaissant pendant l'initialisation, restent intactes ; le verrou système de la destination reste détenu jusqu'à la fin de la publication. Cela ne simule pas une coupure électrique physique.
• La capture d'identifiants secrets rejette les clés JSON dupliquées, y compris les objets imbriqués et les noms équivalents après échappement. Les tests conservent le comportement valide des tableaux/pointeurs/chaînes, l'expurgation des erreurs et le rejet via les véritables IPC CLI/démon.
• Un dispositif de profil HTTP retardé confirme que la latence réseau OAuth ne peut pas prolonger la validité du jeton d'accès. Les régressions existantes d'échange avec le fournisseur et d'annulation au verrouillage/à la déconnexion réussissent. Les tests WebSocket du relais incluent désormais Ping/Pong ; les réponses de contrôle utilisent le même délai d'envoi de dix secondes que les données en attente. Aucun test prolongé de socket saturé n'a été effectué.
• Clippy sur l'espace de travail/toutes les cibles avec -D warnings, le formatage Rust/Dart, les espaces du diff et les vérifications locales des liens/blocs Markdown ont réussi. L'analyse Flutter n'a signalé aucun problème ; les 14 tests de widgets ont réussi.
• La FFI Windows recompilée a réussi les vérifications avec données synthétiques jetables pour l'initialisation sans fichiers de préparation restants, le refus des tickets périmés après verrouillage, la persistance chiffrée des comptes après réouverture, l'état limité aux métadonnées et la déconnexion locale. Le dispositif a ensuite été supprimé.
• Journaux locaux : target/review-20260909-rust-tests.log, target/review-20260909-clippy.log et target/review-20260909-flutter-tests.log. Rust a utilisé D:/memories-build-cache/cards avec une tâche de compilation/un thread de test.
• Aucune autorisation Microsoft/Google réelle, exécution native Android/iOS ni vérification d'exécution Linux/macOS n'a été effectuée pendant cette revue. Les binaires installés n'ont pas été remplacés ; la CI distante et les artefacts de production n'ont pas été validés.

Autorisation cloud (2026-09-09)

• Espace de travail Rust Windows : 47 tests réussis, y compris les régressions d'autorisation cloud et de défaillance du stockage. Neuf tests auxiliaires sont exclus de la découverte et explicitement lancés par leurs scénarios parents.
• Clippy sur l'espace de travail/toutes les cibles avec -D warnings, le formatage Rust et les vérifications des espaces du diff ont réussi. L'ajustement final du lancement non bloquant du navigateur a été suivi des tests cloud CLI, de Clippy et d'une nouvelle compilation CLI/FFI.
• Les deux fournisseurs OAuth ont été exercés avec des dispositifs HTTP locaux : PKCE, état, identité du compte, vérifications de périmètre, jetons d'actualisation manquants, limites de réponse, redirections rejetées et erreurs génériques sans réflexion de secrets.
• Un véritable test de socket en boucle locale a rejeté un callback sans rapport et accepté le callback correspondant sans refléter son code dans la réponse HTTP.
• Les régressions du cœur ont vérifié la liaison appelant/fournisseur, le rejeu, l'annulation au verrouillage/à la déconnexion, la persistance chiffrée, l'isolation audit/MCP et l'absence de jetons cloud dans les charges utiles déchiffrées de sauvegarde et de synchronisation.
• Un dispositif FFI Windows temporaire utilisant des jetons synthétiques a réussi la persistance d'autorisation après fermeture/réouverture, l'annulation par memories_lock_all et la déconnexion. Le dispositif a ensuite été supprimé.
• Aucune configuration de client enregistré ni compte cloud réel n'a été fourni, donc le consentement Microsoft/Google réel et l'émission de jetons restent non vérifiés. Aucun fichier cloud n'a été téléversé. Aucun appareil/émulateur Android n'était connecté ; l'exécution native Android/iOS et l'interface mobile de connexion n'ont pas été validées pour cette modification.
• Des binaires locaux de développement ont été compilés ; les binaires CLI/démon installés n'ont pas été remplacés et aucun résultat CI distant ou de production n'est revendiqué.

Validation avant push (2026-09-09)

• Régression de l'espace de travail Rust : 30 réussis ; deux auxiliaires enfants IPC restent explicitement invoqués par le scénario parent. Les aller-retours de collision d'ID court, d'historique, de référence protégée et d'autorisation sont inclus.
• Clippy sur l'espace de travail/toutes les cibles avec -D warnings et le formatage Rust ont réussi. La vérification de parité des ID courts a été mise à jour vers is_multiple_of ; les deux tests unitaires d'ID ont réussi à nouveau après cette correction équivalente de lint.
• Le formatage Dart, l'analyse Flutter et les 14 tests de widgets ont réussi.
• Les tests Windows ont utilisé D:/memories-build-cache/cards, une tâche de compilation et un thread de test. Les anciens fichiers PDB causant LNK1201/LNK1207 ont été conservés avec un suffixe .pre-push-20260909 avant régénération. Le journal de l'espace de travail réussi est target/push-20260909-rust-tests.log.
• Les binaires de production et les artefacts Android n'ont pas été recompilés pendant cette vérification ; les anciennes empreintes d'artefacts ci-dessous ne valident pas le nouveau protocole d'ID courts. Les résultats CI distants sont suivis séparément.

Suivi de la longueur des mots de passe (2026-09-09)

Les mots de passe locaux et de sauvegarde n'ont plus de politique applicative de longueur minimale ou maximale. La saisie vide est acceptée. La confirmation, les paramètres Argon2id, l'authentification, le périmètre sudo et le stockage chiffré restent en place.

• Une nouvelle régression du cœur a réussi pour les longueurs 0, 1 et 4096 : création du stockage, authentification, déverrouillage, sauvegarde et restauration ; les mots de passe incorrects sont rejetés.
• Clippy sur l'espace de travail/toutes les cibles avec -D warnings et le formatage Rust ont réussi.
• L'analyse Flutter et les 14 tests de widgets ont réussi, y compris l'initialisation avec des mots de passe vides et à un caractère tout en conservant l'étape de confirmation.
• La CLI/FFI Windows a été recompilée et le démon local redémarré. Un dispositif temporaire séparé utilisant la FFI de production a réussi l'initialisation/déverrouillage/sudo à un caractère, un mot de passe de sauvegarde vide et une restauration protégée par un mot de passe à un caractère.
• Les deux ABI Android et l'APK à point d'entrée normal ont été recompilés. Les vérifications d'égalité des bibliothèques natives source/fusionnée et dépouillée/APK ont réussi. L'intégration d'exécution Android n'a pas été répétée pour cette seule modification de longueur ; le dispositif de test natif utilise désormais un mot de passe à un caractère pour la prochaine exécution sur appareil.

Ces empreintes remplacent les anciens enregistrements d'artefacts. Le journal de compilation est target/password-length-android-build.log ; les empreintes ABI détaillées se trouvent dans target/password-length-artifacts.json.

Suivi des cartes, des métadonnées protégées et des OTP

Les vérifications fonctionnelles et artefacts suivants remplacent les empreintes de compilation de base enregistrées plus loin dans ce document. Tous les identifiants secrets utilisés pendant la validation étaient synthétiques ; aucun identifiant de compte fourni ni serveur de courrier n'a été utilisé.

• Régression de l'espace de travail Rust : 25 réussis. Le scénario IPC CLI étendu et les vérifications RFC 6238/entrées mal formées ont aussi réussi après leurs derniers ajouts de tests. Deux tests auxiliaires sont délibérément ignorés lors de la découverte et exécutés explicitement par le scénario IPC (injection d'identifiants secrets et sudo de processus voisin).
• Formatage Rust et Clippy sur l'espace de travail/toutes les cibles avec -D warnings : réussis. Les vérifications de débogage Windows ont utilisé D:/memories-build-cache/cards et -j 2.
• Analyse Flutter et les 12 tests de widgets : réussis. La couverture comprend un graphe de taille téléphone, les liens retour dirigés, les aperçus masqués, l'autorisation OTP privée, l'expiration et la fermeture du dialogue OTP lors du passage en arrière-plan/verrouillage.
• L'espace de travail Windows de production a été recompilé. Une véritable CLI de production avec un stockage chiffré temporaire a enregistré Python 3.13.1 et son répertoire exécutable, marqué le coffre comme local uniquement et retrouvé l'observation par recherche de carte. Le dispositif et le démon ont été supprimés après la vérification.
• Les bibliothèques FFI Android ARM64/x86_64 ont été recompilées. L'émulateur API 35 x86_64 a réussi le véritable test d'intégration FFI : cartes/liens/graphe, recherche dotenv limitée aux clés, génération TOTP, refus de lecture d'identifiants secrets, audit et verrouillage/déverrouillage. Journal : target/cards-android-native-test.log.
• L'APK de développement à point d'entrée normal a été recompilé et installé après le test d'intégration. Le démarrage, l'initialisation du mot de passe, la création de bibliothèque et l'ouverture du nouveau formulaire de carte protégée ont réussi. La soumission manuelle supplémentaire du formulaire de compte a été interrompue lorsque l'émulateur a disparu d'ADB ; ce scénario manuel supplémentaire n'est pas enregistré comme réussi. XML de démarrage : target/cards-android-startup.xml ; journal de compilation : target/cards-android-build.log.
• Les bibliothèques natives empaquetées ont été vérifiées par ABI : la source est égale à la sortie fusionnée de Gradle, et la sortie dépouillée de ses symboles est égale à l'entrée APK. Preuves et tailles : target/cards-artifacts.json.

Les tests de sécurité du cœur couvrent le stockage chiffré séparé des identifiants secrets, l'échec atomique, l'absence de secrets dans recherche/liste/graphe/MCP/audit et les octets en clair de la base, le refus de remplacement des références, la restriction d'hôte/l'injection d'en-têtes, l'exclusion des données locales uniquement de l'appairage/synchronisation/sauvegarde et les références OTP après synchronisation/restauration. La couverture RFC 6238 comprend les six horodatages standard pour SHA-1/SHA-256/SHA-512, ainsi que la sortie à six chiffres et le rejet de graines/périodes mal formées. Les tests d'en-têtes HTTP utilisent des valeurs synthétiques et vérifient le marquage des en-têtes sensibles ; aucune requête authentifiée à un service de production n'a été effectuée.

Artefacts actuels (compilation de développement, non signée pour distribution) :

SHA-256 Rust empaqueté :

Les limitations des plateformes à la fin de ce document s'appliquent toujours. Cette section enregistre la validation locale ; aucun résultat CI distant n'y est revendiqué.

Espace de travail Rust Windows de référence

Hôte : Windows x86_64, Rust stable 1.98, chaîne MSVC, SQLite intégré.

Le test ignoré est l'exécutable enfant utilisé par le test IPC et il est explicitement exécuté dans ce contexte avec injection d'identifiants secrets. Ce n'est pas un scénario de sécurité omis.

Les tests exercent le chiffrement authentifié et l'altération du transport, l'état SQLite chiffré, les mots de passe incorrects, la troncature des points de contrôle, l'ordre des fragments, les permissions, l'approbation et la révocation des appareils, le refus de réautorisation d'identité, l'appartenance partagée, le rejeu, les révisions simultanées, la résolution des divergences de politique et la restauration indépendante de sauvegarde. Un véritable test de démon CLI couvre le déverrouillage, sudo au terminal, le refus de lecture des identifiants secrets, l'approbation d'empreinte exécutable, la suppression des sorties enfants, l'audit signé, le périmètre MCP et le verrouillage. Un véritable test WebSocket vérifie le routage actif et le nettoyage des salles après déconnexion.

L'implémentation des tubes nommés Windows utilise un cadrage bloquant. Une tentative d'implémentation PIPE_NOWAIT a échoué à la régression du démon réel et a été remplacée ; les limites de disponibilité pour un même utilisateur sont documentées dans SECURITY.md.

Artefacts Windows de référence (chemins relatifs à la copie de travail ; les sorties de compilation sont ignorées par Git). La CLI a également réussi l'exécution de --version et --help :

Flutter et bibliothèques mobiles natives

Chaîne d'outils : Flutter 3.44.2 / Dart 3.12.2, Android NDK 28.2.13676358, plateformes Android SDK 35, 36 et 37.0, Gradle 9.1.0.

Les tests de widgets vérifient qu'un échec de démarrage natif laisse la bibliothèque verrouillée, que le passage en arrière-plan ferme les dialogues de contenu et efface l'état d'autorisation, et que l'expiration après inactivité ferme aussi un dialogue de contenu déjà ouvert. Les réponses asynchrones tardives sont rejetées après le changement de génération d'autorisation mobile. Le test d'intégration natif utilise une base temporaire sur l'appareil plutôt qu'un serveur simulé. Il initialise le véritable service Rust, écrit et lit une mémoire, exige l'élévation pour ajouter des identifiants secrets, refuse leur lecture, vérifie la chaîne d'audit, verrouille tous les handles natifs et déverrouille le contenu persistant sans restaurer l'élévation. Le répertoire du dispositif est supprimé après le test.

L'émulateur exécute une image API 35 x86_64 existante en mode lecture seule, sans enregistrer d'instantané. La sortie des tests est disponible localement dans target/android-native-test.log. La compilation Android émet un ancien avertissement de version XML du SDK provenant de la chaîne d'outils d'un plugin, mais cela n'a pas empêché la compilation ni l'exécution native. Le SDK de compilation de l'application est 37 pour satisfaire les exigences du plugin de stockage sécurisé.

L'APK final à point d'entrée normal a été recompilé après les tests d'intégration, installé et exercé par automatisation de l'interface Android. Les vérifications ont réussi pour le démarrage avec le véritable plugin de stockage sécurisé, l'initialisation du mot de passe, la création d'une bibliothèque et d'une mémoire, la lecture de cette mémoire, le passage en arrière-plan avec contenu ouvert, le retour à un écran verrouillé et le déverrouillage pour relire le contenu persistant. Cela vérifie l'application normale, pas seulement le point d'entrée des tests d'intégration. Les preuves de l'interface sont stockées dans 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 et target/android-ui-unlocked-persisted-content.xml. Seules des données de test synthétiques ont été utilisées. L'émulateur en lecture seule a été arrêté après vérification.

APK de référence : mobile/build/app/outputs/flutter-apk/app-debug.apk, 177,630,089 octets. SHA-256 : 1d671906316c139eca786e89a5cca2c5d7895a825c0d58f4c32e71e6ff8be382. Il s'agit d'un APK de développement signé pour le débogage, pas d'une version de boutique.

arm64-v8a et x86_64 incluent tous deux le moteur Flutter et la bibliothèque Rust FFI. Les bibliothèques JNI sources correspondent aux bibliothèques fusionnées de Gradle ; les bibliothèques de Gradle dépouillées de leurs symboles correspondent au contenu de l'APK final. La suppression des symboles explique pourquoi une comparaison directe des empreintes source/APK diffère. Valeurs SHA-256 des bibliothèques Rust empaquetées :

Le cache de compilation de débogage Windows a été déplacé vers D:/memories-build-cache/20260908/windows-debug pour libérer de l'espace disque pour la validation de l'émulateur. Les sources et artefacts de production restent dans la copie de travail. Les compilations Android ont utilisé un target/gradle-home propre à la tâche pour éviter l'ancienne configuration de proxy de l'hôte, ainsi qu'un dépôt local contenant les JAR exacts du moteur Flutter vérifiés avec les métadonnées HTTPS officielles. Aucun code moteur ni source du cache de plugin n'a été modifié. Les répertoires caches, wrapper et jdks de ce répertoire Gradle sont des jonctions vers le cache Gradle de l'hôte.

Plateformes et validation restante

• Les vérifications d'exécution de bureau Linux et macOS n'ont pas été exécutées sur cet hôte Windows. La compilation croisée Android n'établit pas la correction de l'exécution Linux ou macOS.
• La compilation Xcode iOS, l'exécution sur simulateur/appareil, la signature, le comportement de Keychain et le XCTest natif nécessitent un hôte macOS et n'ont pas été exécutés ici.
• L'exécution sur appareil Android ARM64 physique n'a pas eu lieu ; une compilation croisée réussie seule n'établit pas le comportement matériel ni les garanties de stockage sécurisé.
• La CI définit des vérifications Rust Windows/Linux/macOS et Flutter, mais aucun résultat CI distant n'est revendiqué. Aucune signature de production ni publication en boutique n'a eu lieu.
• Aucune revue cryptographique indépendante, test d'intrusion ni test de ressources à grande échelle n'a été effectué. Consultez SECURITY.md avant d'utiliser de véritables secrets.

Valeurs par défaut du client et génération de compétence (2026-10-01)

• memories default set/get/delete effectue un aller-retour sous un --home jetable, rejette les clés inconnues et les valeurs type invalides, et supprime defaults.json lorsqu'il est vide.
• Les commandes de liste appliquent les valeurs par défaut vault / type / category lorsque les options sont omises.
• Les commandes world/thing/event de persona déterminent le coffre/la ressource omis à partir des valeurs par défaut persona / vault (VAULT/ASSET, forme avec barre oblique ou ressource avec coffre par défaut).
• memories skill generate / agents generate écrivent AGENTS.md ou un SKILL.md disposé en compétence hors ligne sans persona ; elles refusent l'écrasement sans --force.
• cargo test --workspace --locked couvre les tests unitaires et d'intégration de ces chemins.