Guide d'utilisation de Memories

Ce document explique comment accomplir les principales tâches déjà implémentées avec la CLI actuelle. Remplacez VAULT_ID, ASSET_ID et les autres identifiants en majuscules des exemples par les identifiants courts effectivement retournés par les commandes. Les mots de passe sont lus sans écho dans un terminal interactif. Il n'existe ni argument ni variable d'environnement pour les mots de passe. L'application ne limite pas la longueur des mots de passe locaux et de sauvegarde ; une saisie vide est également acceptée. Les étapes qui nécessitent une confirmation demandent une seconde saisie.

Toutes les commandes de données nécessitent d'abord un démon en cours d'exécution utilisant le même répertoire de données. Options globales :

Les commandes produisent du JSON versionné. En cas d'échec, le code de sortie est non nul. Les mots de confirmation USE et APPROVE restent en anglais quelle que soit la langue de l'interface.

Linux peut exécuter la CLI, le démon, le relais, la FFI et la page d'état décrite ci-dessous. Linux ne dispose pas d'une zone de notification native. Le client mobile ne propose ni interface de recherche avec modèle, ni synchronisation en arrière-plan, ni import de codes QR OTP par la caméra. L'appairage des appareils hébergés permet de scanner un code d'appairage ; voir Secrets de bout en bout entre appareils. La validation de bout en bout avec de vrais comptes cloud n'est pas encore terminée. La ligne de commande permet d'importer HOTP, otpauth:// et otpauth-migration://, et de décoder des images de codes QR OTP avec --image.

Trouver l'entrée adaptée à votre tâche

Si vous ne connaissez pas les arguments, consultez d'abord l'aide générale, puis celle des sous-commandes successives. L'aide ne nécessite pas de démon :

memories --help
memories --lang zh memory --help
memories --lang zh memory put --help

--lang zh change uniquement la langue de l'aide et des messages, sans modifier les noms des commandes ni la syntaxe des arguments. Les exemples sh de ce document utilisent un shell POSIX ; le \ en fin de ligne sert à poursuivre une commande sur plusieurs lignes. Dans PowerShell/CMD, réunissez-la sur une seule ligne.

Démarrer le démon et initialiser un coffre

Démarrez le service dans un terminal. Il n'accepte que les connexions de l'utilisateur courant du système : Windows utilise des canaux nommés, Linux et macOS des sockets Unix.

memories daemon

Ouvrez un autre terminal pour initialiser l'appareil, créer un coffre, verrouiller et déverrouiller :

memories init --name laptop
memories vault create Personal
memories vault list
memories lock
memories unlock
memories status
memories identity

--name est facultatif ; le nom d'appareil par défaut est local-device. identity affiche l'identité publique de cet appareil. L'initialisation, le déverrouillage et sudo nécessitent la saisie d'un mot de passe dans un terminal interactif. Ne faites pas pointer --home vers un dossier ordinaire existant : le programme en restreindra les permissions.

Le stockage local (store) désigne ici le répertoire de données choisi par --home ; l'initialisation crée l'identité locale et la protection par mot de passe. Un coffre (vault) est une collection de données répartie selon les membres et les permissions ; un stockage peut contenir plusieurs coffres. Avec un répertoire personnalisé, le service et chaque commande cliente doivent utiliser le même --home PATH. Un stockage existant nécessite seulement unlock : ne répétez pas init. Pour ajouter un nouvel appareil à une identité existante, effectuez d'abord l'appairage des appareils, sans créer au préalable de coffre Personal ou « Cet appareil ».

Après ces étapes, créez avec un éditeur un fichier UTF-8 notes.md et écrivez une note de test contenant « 项目 ». Remplacez VAULT_ID dans l'exemple suivant par le champ id retourné par vault create ou vault list pour enregistrer et rechercher votre première mémoire :

memories memory put VAULT_ID --title "项目笔记" --input notes.md
memories memory search VAULT_ID "项目"

Le champ id du résultat d'enregistrement est l'ASSET_ID utilisé ensuite pour la lecture. Utilisez memory pour les notes ordinaires, card pour les étiquettes, catégories et relations, et file pour les fichiers originaux tels que les PDF, qui ne deviennent pas automatiquement du texte recherchable. Utilisez credential pour les secrets ; ne les mettez pas dans des notes ordinaires.

Un unlock ordinaire autorise les opérations sur les données ordinaires dans la limite des permissions, sans donner accès au contenu privé, aux fichiers ou aux identifiants. sudo est une session d'autorisation locale, sans privilèges d'administrateur du système. Elle utilise le même mot de passe local, dure au maximum 15 minutes, expire après 5 minutes d'inactivité et appartient uniquement au processus parent de ce terminal. Le verrouillage ou le redémarrage du service la supprime. Le déverrouillage ordinaire expire après 15 minutes d'inactivité.

Afficher ou créer une configuration non secrète :

memories config path
memories config init
memories config init --output ./development.toml
memories --config ./development.toml config show

config init n'écrase pas de fichier existant. config show n'ouvre pas le stockage chiffré. Les paramètres comprennent storage_dir, relay_url, [desktop] et [rag]. N'inscrivez dans ce fichier aucun mot de passe, clé privée, jeton OAuth ou autorisation MCP. Après un changement de répertoire de stockage ou de configuration des modèles, redémarrez également le démon.

Écrire, lire et rechercher des mémoires et des fiches

Écrire une mémoire ordinaire. Placez le contenu dans un fichier UTF-8 et transmettez-le avec --input :

memories memory put VAULT_ID --title "项目笔记" --input notes.md
memories memory search VAULT_ID "项目"
memories memory read VAULT_ID ASSET_ID
memories memory history VAULT_ID ASSET_ID
memories memory diff VAULT_ID ASSET_ID FROM_REVISION
memories memory diff VAULT_ID ASSET_ID FROM_REVISION --to TO_REVISION
memories memory grep VAULT_ID 'project|release' -i -n

memory grep applique une expression régulière ligne par ligne au contenu déchiffré des mémoires ordinaires du coffre sélectionné et affiche DOCUMENT_ID:LINE. Avec -n / --line-number, il affiche DOCUMENT_ID:LINE_NUMBER:LINE ; -i / --ignore-case ignore la casse. Les documents privés, versions en conflit, fiches, fichiers et identifiants sont exclus, comme le contenu privé dans la recherche ordinaire. Sans correspondance, aucune sortie n'est produite.

FROM_REVISION et TO_REVISION proviennent du champ revision retourné par history, et non du champ id. La version de référence est un argument positionnel, et non --from ; si --to est omis, la comparaison porte sur le head courant.

Chaque création ou mise à jour ajoute une version au DAG des révisions signées du coffre : mémoires ordinaires, fiches de connaissance/brain, métadonnées des fiches protégées, fichiers et identifiants. history pour memory / card / file liste les versions (revision, horodatage, auteur, statut head, résumé) ; read --revision lit un contenu historique ; diff produit un diff textuel unifié, incluant le titre et les métadonnées de la fiche. Les diffs de fichiers omettent le contenu binaire et comparent uniquement les métadonnées et la longueur ; le contenu secret des identifiants ne peut pas être retourné par diff/read. Les révisions sont conservées avec le coffre à long terme, sans élagage automatique.

Ajoutez --revision REVISION pour lire une version historique. Ajoutez --id ASSET_ID pour remplacer un enregistrement existant. S'il existe plusieurs versions non fusionnées, examinez l'historique, puis soumettez avec --id ASSET_ID --resolve une nouvelle version référençant simultanément ces versions parentes. Supprimer un enregistrement actuellement visible :

memories memory delete VAULT_ID ASSET_ID

La suppression n'efface pas l'historique signé. --private marque l'enregistrement comme privé. Les enregistrements privés nécessitent sudo et sont exclus de la recherche ordinaire et de MCP.

Les fiches de connaissance utilisent les mêmes sous-commandes d'actifs et peuvent comporter des étiquettes, sources, alias, notes, catégories et relations. card list (également disponible au premier niveau via memories list / memories ls) peut omettre l'identifiant du coffre pour parcourir tous les coffres accessibles ; chaque résultat contient vault. --type knowledge|brain|persona|workflow|account|env|token|totp|hotp|otp filtre selon summary.type : knowledge est une fiche de connaissance ordinaire ; brain est une fiche structurée avec résumé et liens typés ; otp désigne totp+hotp. --otp équivaut à --type otp. --category filtre par catégorie et --group-by-category regroupe par catégorie :

memories card put VAULT_ID --title "一个想法" --input notes.md --tag design --source "会议" --alias "设计备忘" --notes "工作坊" --category design
memories list
memories ls --type knowledge
memories card list --type brain
memories list --type otp
memories ls --otp --category security
memories card list VAULT_ID --category design
memories card list VAULT_ID --group-by-category
memories card brain VAULT_ID --title "Alice" --abstract "连接设计与工程的产品负责人" \
  --link CARD_A=reports-to --link "OTHER_VAULT/CARD_B=collaborates|共同路线图" \
  --alias "Alice" --notes "组织图" --category people
memories card brain VAULT_ID --id BRAIN_ID --title "Alice" --abstract "更新后的摘要" --link CARD_B=partner
memories card link VAULT_ID CARD_A CARD_B --relation supports
memories card unlink VAULT_ID CARD_A CARD_B --relation supports
memories card graph VAULT_ID
memories card graph VAULT_ID --include-private
memories card search VAULT_ID design
memories card list VAULT_ID
memories card read VAULT_ID CARD_ID
memories card delete VAULT_ID CARD_ID

Comme memory delete, card delete retire seulement la fiche de la vue courante ; l'historique signé conserve les versions antérieures. Supprimer une fiche privée ou protégée nécessite sudo.

Les fiches brain enregistrent un abstract en texte brut recherchable, sans en faire un secret protégé, ainsi que des liens entre coffres { vault?, card, role?, note? }. La syntaxe de --link est [VAULT/]CARD[=ROLE][|NOTE] ; mettez toute la valeur entre guillemets si elle contient | ou des espaces, afin que le shell ne l'interprète pas comme un pipeline. summary.type vaut brain et contient link_count. Les listes, graphes et lectures résolvent les titres et types des liens lorsque les permissions le permettent ; une cible absente ou inaccessible est marquée broken, sans suppression en cascade. La recherche indexe le titre, le résumé, les rôles/notes des liens et les résumés des cibles publiques du même coffre, jamais les secrets. Les liens brain internes au coffre apparaissent aussi dans card graph.

L'éditeur mobile prend en charge l'écriture manuscrite et la reconnaissance de texte dans des photos/images, entièrement sur l'appareil ; voir Écriture manuscrite et reconnaissance de texte.

Fiches de workflow et modèles de listes

Le summary.type des fiches de workflow vaut workflow. Les étapes ordonnées sont conservées dans les révisions de la fiche ; chaque étape a l'état pending, active, done ou skipped, et la fiche possède aussi un état global. La syntaxe de --step est TITLE ou ID:TITLE, éventuellement suivi de =CARD pour lier une fiche. Répétez l'option pour chaque étape :

memories card workflow VAULT_ID --title Release --step "Write notes" --step Ship
memories card workflow-update VAULT_ID WORKFLOW_ID --advance
memories card workflow-update VAULT_ID WORKFLOW_ID --step STEP_ID --step-status done
memories card list --type workflow

--advance fait avancer l'étape indiquée ; à défaut, l'étape actuellement active, ou, s'il n'y en a pas, la première étape pending.

Les modèles de listes sont aussi des fiches de type workflow, dont le champ template vaut true. Pour créer un modèle, utilisez --template sans valeur et fournissez --assignee, --summary et --goal. --assignee peut être l'identifiant d'une fiche persona, d'une persona ou un nom quelconque ; --assignee-name est le nom affiché et reprend par défaut celui de la persona lorsqu'une fiche persona est référencée. --template TEMPLATE_ID copie les champs de liste et les liens du workflow du modèle dans une tâche :

memories card workflow VAULT_ID --template --assignee PERSONA_ID --summary "每周发布检查" --goal "按时发布"
memories card list --type workflow --template
memories card workflow VAULT_ID --template TEMPLATE_ID --workflow WORKFLOW_ID --archive MEMORY_ID
memories card workflow-update VAULT_ID TASK_ID --acceptance "已发布并通知" --status done

--workflow relie une autre fiche de workflow du même coffre ; --archive archive une mémoire ou une fiche et peut être répété. Les options --clear-workflow et --clear-archives de workflow-update retirent respectivement ces deux types de liens. Si la tâche n'a pas ses propres étapes, --advance, --step, --step-status et --status agissent sur le workflow lié. Le rapport d'acceptation --acceptance peut rester vide jusqu'à la fin de la tâche.

Fiches persona

Les fiches persona synchronisent la personnalité et le comportement entre des produits comme Grok Bot / Muse. La fiche persona du coffre et ses archives associées constituent la source faisant autorité.

memories persona import VAULT_ID /path/to/xiaoya-persona
memories card list --type persona
memories card read VAULT_ID PERSONA_ID
memories card history VAULT_ID PERSONA_ID
memories card diff VAULT_ID PERSONA_ID REVISION_ID
memories persona append-event VAULT_ID PERSONA_ID --text "行为记录" --kind note

• Noyau (core) : manière de parler et de jouer le rôle ; révisé via persona put / persona_card.
• Archives (archives) : fiches de connaissance indépendantes pour les contrats, journaux, tenues, points de vue, etc., liées par archives de la persona ; ne les recopiez pas dans le noyau.
• Événements de comportement : append-event ajoute à l'archive events, en ajout uniquement.

L'état du monde, les objets, les automatisations et les conversations entre personas sont également gérés par les sous-commandes persona. Lorsque VAULT_ID PERSONA_ID est omis, la persona des valeurs par défaut du client est utilisée :

memories persona world-get VAULT_ID PERSONA_ID
memories persona world-set VAULT_ID PERSONA_ID --place "书房" --weather-condition "多云" --weather-temp-c 26
memories persona world-rollover VAULT_ID PERSONA_ID
memories persona thing put VAULT_ID PERSONA_ID --id notebook --name 笔记本 --count 1 --attrs '{"color":"blue"}'
memories persona thing list VAULT_ID PERSONA_ID
memories persona thing attr set VAULT_ID PERSONA_ID --id notebook --path color --value '"red"'
memories persona dice-roll VAULT_ID PERSONA_ID --sides 6
memories persona schedule-list VAULT_ID PERSONA_ID
memories persona automation list VAULT_ID PERSONA_ID
memories persona automation trigger VAULT_ID PERSONA_ID --id morning --source manual
memories persona chat send VAULT_ID PERSONA_A PERSONA_B --text "你好"
memories persona chat history VAULT_ID PERSONA_A --with PERSONA_B --limit 20

• État du monde : world-set met à jour le lieu, la posture, la tenue, les quantités d'objets, la météo, les dés, la roue, le planning, etc. ; world-rollover commence explicitement un nouveau jour de registre lors du changement de jour et efface uniquement les champs quotidiens comme meals, orders_done, le bref résumé look et counters_today, en conservant les compteurs cumulés.
• Objets (things) : thing put/get/list/delete/image gère des objets quelconques ; thing attr get/set/delete lit et écrit un attribut individuel via un chemin à points ou un JSON Pointer ; attrs est du JSON libre.
• Automatisation : automation put/list/run/trigger/delete gère les hooks conservés dans l'état du monde, avec le timezone de la persona. Les webhook_out sortants peuvent viser uniquement des URL correspondant exactement à la liste autorisée ; la liste vide par défaut bloque tous les POST sortants. Gérez-la avec automation webhook-allow --add URL / --remove URL. Le jeton webhook n'est jamais retourné dans les réponses ; seul webhook_token_set apparaît.
• Conversation : messages entre deux fiches persona d'un même coffre. L'envoi déclenche le hook d'automatisation chat_message des deux côtés, dont la charge utile exclut le corps du message. chat list affiche les conversations ; lire history ne marque pas les messages comme lus : utilisez chat mark-read.

Voir le guide des fiches persona en anglais.

La création d'une fiche ordinaire permet aussi de répéter --link TARGET_ID=RELATION. Ces relations doivent viser des fiches du même coffre. Le graphe omet les nœuds supprimés, en conflit ou non autorisés, ainsi que les arêtes les reliant. --include-private nécessite sudo.

Fichiers privés :

memories sudo
memories file import VAULT_ID document.pdf
memories file export VAULT_ID FILE_ID exported.pdf
memories file history VAULT_ID FILE_ID
memories file diff VAULT_ID FILE_ID FROM_REVISION

file import accepte --title et --id. file export accepte --revision. file history liste les révisions signées du fichier ; file diff compare uniquement le titre, les métadonnées et la longueur, sans afficher le contenu binaire.

Utilisez file exec pour transmettre une configuration gérée à un programme local. {file} dans les arguments de commande est remplacé par le chemin absolu du fichier temporaire :

memories sudo
memories file import VAULT_ID ./Caddyfile
# 将返回的文件 ID 填入 FILE_ID；这里使用 Caddy 2 的 Caddyfile 格式。
memories file exec VAULT_ID FILE_ID -- caddy run --config "{file}" --adapter caddyfile

Les permissions sont les mêmes que pour file export : déverrouillage, accès au coffre et memories sudo dans le même terminal. Ajoutez --revision REVISION avant -- pour utiliser une version historique. Même si la lecture concerne un démon distant ou hébergé, le programme s'exécute sur la machine locale de la CLI, avec l'utilisateur courant. La commande lance directement le programme sans shell et conserve le répertoire de travail, les variables d'environnement, les entrées/sorties standard et le code de sortie, sans limite d'exécution de cinq minutes ni réponse JSON de réussite.

Le répertoire et les fichiers temporaires sont accessibles uniquement à l'utilisateur courant : permissions Unix 0700/0600, ACL utilisateur sous Windows. Le programme doit s'exécuter au premier plan : le fichier temporaire reste jusqu'à la fin du processus enfant et est aussi nettoyé si le lancement échoue. Sous Windows, Ctrl+C/Ctrl+Break, et sous Unix SIGINT/SIGTERM/SIGHUP, déclenchent le nettoyage à la sortie, avec une attente maximale de dix secondes, puis la terminaison du processus enfant direct. Les signaux Unix sont transmis à l'enfant ; les événements de console Windows sont reçus par les processus de la même console.

Pendant l'exécution, la configuration est en clair ; le programme et ses plugins peuvent la lire et l'afficher, et la sortie n'est pas expurgée. Verrouiller le coffre ou révoquer l'autorisation ne récupère pas les copies déjà remises et n'arrête pas le programme. L'arrêt forcé de Memories, une coupure de courant ou la fermeture de la console Windows peut laisser des fichiers temporaires. Une suppression n'est pas un effacement sécurisé ; les descendants en arrière-plan détachés du parent ne sont pas gérés. Chaque exécution utilise un seul instantané fixe nommé config, sans mise à jour automatique, reload, développement de modèles ni import de fichiers associés. Les chemins relatifs sont interprétés selon les règles du programme cible ; utilisez de préférence des chemins absolus pour les configurations et certificats associés, et précisez explicitement le format de configuration si nécessaire.

Utilisez tels quels les identifiants courts retournés par les listes et recherches. Les UUID longs, hachages complets de révision et identifiants préfixés sont refusés. Si l'entrée est ambiguë, la commande échoue ; relancez une liste ou une recherche.

Enregistrer Python uniquement localement :

memories local-python
memories local-python --program /path/to/python

Cette commande lance l'interpréteur choisi en mode isolé, enregistre sa version et le répertoire de l'exécutable, sans collecter de variables d'environnement. Le résultat est écrit dans le coffre « Cet appareil » marqué local_only.

Recherche et réponses avec citations

Faites d'abord utiliser au démon la même configuration contenant [rag]. L'import d'un texte UTF-8 ou Markdown crée une fiche de connaissance ordinaire et retourne le nombre estimé de segments :

memories rag ingest VAULT_ID notes.md --title "研究笔记" --source "本地文件"
memories memory search VAULT_ID "中文 关键词"
memories rag search VAULT_ID "关键词" --mode bm25 --match-mode all

Options de rag search et rag ask :

Installer les poids EmbeddingGemma intégrés et créer l'index vectoriel en mémoire :

memories rag model-install
memories rag index VAULT_ID
memories rag status VAULT_ID
memories rag search VAULT_ID "这段文档在说什么" --mode vector
memories rag search VAULT_ID "找出证据" --mode hybrid --limit 8
memories rag ask VAULT_ID "根据证据概括"

model-install n'initialise pas le stockage chiffré. Par défaut, les poids sont installés dans models/embeddinggemma sous le répertoire de données choisi. L'inférence locale s'exécute dans le processus Memories et ne nécessite pas Ollama. Les recherches vectorielles et hybrides calculent aussi les embeddings manquants à la demande lorsque l'index n'est pas entièrement construit.

rag ask nécessite une adresse de génération dans la configuration. Utilisez --mode bm25 pour une recherche exclusivement lexicale ; tout appel de questions-réponses nécessite néanmoins une adresse de génération. Sans éléments probants, le service de génération n'est pas appelé et insufficient_evidence vaut vrai dans le résultat. [S1] dans la réponse est seulement une étiquette de citation propre à ce résultat. Pour ouvrir l'original, utilisez l'id de l'actif du résultat et non le hachage du segment :

memories memory read VAULT_ID ASSET_ID

Les PDF, DOCX et fichiers binaires ne font pas l'objet d'une extraction automatique de texte. Convertissez-les en texte UTF-8 avant l'import. N'importez pas de texte confidentiel comme fiche ordinaire. Redémarrez le démon après tout changement de configuration des modèles.

Les embeddings, la génération et le reclassement distants se configurent dans [rag.embedding], [rag.generation] et [rag.rerank]. Pour les clés API, indiquez uniquement le nom de la variable d'environnement, par exemple api_key_env = "GEMINI_API_KEY", et placez la valeur dans l'environnement du démon. Sans [rag.embedding], les embeddings restent produits par le modèle local. Gemini Embedding est une API en ligne, distincte d'EmbeddingGemma hors ligne.

Capturer et utiliser des identifiants et des fiches protégées

Exécutez d'abord memories sudo dans le même terminal.

Ajoutez un identifiant par saisie masquée ou importez un fichier existant. L'import ne supprime pas le fichier source :

memories credential add VAULT_ID "API 令牌"
memories credential import VAULT_ID "SSH 身份" existing-private-key

La commande de capture memories catch équivaut à memories credential catch. Sans source, elle demande une saisie masquée :

memories catch VAULT_ID "数据库密码"

Ajoutez --stdin pour lire un pipeline. --regex extrait une correspondance unique ; avec un groupe de capture, ce groupe est enregistré, sinon la correspondance entière. --json-pointer sélectionne une chaîne JSON. Ces deux options sont incompatibles :

secret-tool | memories catch VAULT_ID "数据库密码" --stdin --regex "password=([^\r\n]+)"
memories catch VAULT_ID "API 令牌" --stdin --json-pointer /token < response.json
memories catch VAULT_ID "API 令牌" --exec secret-tool --json-pointer /token -- issue --format json

--exec PROGRAM lance directement le programme et capture sa sortie standard, ferme l'entrée standard de l'enfant et ignore sa sortie d'erreur. Les arguments du programme suivent -- ; ne placez aucun vrai secret dans les arguments, expressions régulières ou titres. --timeout accepte de 1 à 300 secondes, avec 30 secondes par défaut. L'entrée standard du pipeline attend EOF sans délai maximal. La taille d'entrée est limitée à 1 MiB. Le résultat de réussite contient seulement l'identifiant de l'identifiant secret. Utilisez --id CREDENTIAL_ID pour remplacer un identifiant existant.

Générer des clés dans le coffre. La clé privée n'est pas affichée :

memories credential generate VAULT_ID "笔记本 SSH"
memories credential generate VAULT_ID "笔记本 SSH" --algorithm rsa --bits 4096
memories credential generate VAULT_ID "数据库 CA" --kind tls-ca --algorithm rsa --subject memories-ca
memories credential generate VAULT_ID "数据库服务器" --kind tls --ca CA_ID --algorithm rsa --name db.example.test
memories credential public VAULT_ID KEY_ID

--kind accepte ssh, tls-ca, tls. --algorithm accepte ed25519, rsa, ecdsa. credential public retourne uniquement la clé publique SSH ou le certificat TLS.

Transmettre un identifiant à un programme désigné par un chemin absolu. L'injection utilise l'entrée standard par défaut ; --env autorise explicitement une variable d'environnement. Le SHA-256 du programme doit être confirmé interactivement ou approuvé au préalable avec --approve-digest. Les deux sorties du processus enfant sont supprimées :

memories run --vault VAULT_ID --credential CREDENTIAL_ID /absolute/program/path
memories run --vault VAULT_ID --credential CREDENTIAL_ID --env API_TOKEN /absolute/program/path

Une liaison d'exécution attache un identifiant à l'empreinte d'un programme afin qu'un agent de programmation puisse l'utiliser sans le sudo de votre terminal. credential bind gh nécessite sudo et la confirmation USE : la commande trouve gh dans PATH, enregistre son SHA-256 et conserve la liaison uniquement dans l'état chiffré local. Elle n'est pas synchronisée et est effacée lors d'une restauration de sauvegarde. La liaison expire après --hours heures (8 par défaut, 720 au maximum) et n'est disponible que lorsque le stockage est déverrouillé. Ensuite, run --binding gh -- 参数 lance le programme dans le répertoire courant, injecte l'identifiant dans la variable d'environnement indiquée et restitue la sortie en remplaçant toute occurrence de l'identifiant par [REDACTED] ; --suppress-output supprime cette sortie. La commande se termine avec le code de sortie du programme :

memories credential bind gh --vault VAULT_ID --credential CREDENTIAL_ID --env GH_TOKEN
memories credential bindings
memories credential unbind gh
memories run --binding gh -- pr list --state open
memories hook install --commands gh
memories hook uninstall

--deny 词 refuse les commandes dont les arguments non optionnels contiennent ces mots dans cet ordre ; --ask 词 fait demander confirmation par le hook avant l'exécution. Pour gh, les règles par défaut refusent auth, alias, extension et les alias extensions, ext, et demandent confirmation pour pr merge, repo delete, release delete. --no-default-rules les désactive. Les règles portent seulement sur les mots saisis : les alias précédemment définis via gh alias set ne sont pas développés. Jusqu'à l'expiration de la liaison, tout programme exécuté sous votre identité peut lancer ce programme avec l'identifiant, sans pouvoir lire l'identifiant lui-même via memories. Le programme, ses extensions et ses enfants peuvent toutefois le lire : ne liez que des programmes fiables. Une liaison sans --credential ni --env applique uniquement les règles.

Après avoir affiché les éléments et demandé APPROVE, hook install --commands gh inscrit un hook PreToolUse dans les paramètres utilisateur de Claude Code. Lorsque Claude Code veut exécuter gh ... dans Bash ou PowerShell, le hook remplace ce mot de commande par memories run --binding gh --, en conservant le reste de la ligne. Les appels à gh encapsulés dans $( ), des accents graves, sh -c, xargs, etc., sont refusés avec une explication ; les corps heredoc et les substitutions de commande utilisées comme arguments, par exemple --body "$(cat <<'EOF' ... EOF)", ne sont pas affectés. Les entrées de pipelines ou de redirections sont transmises via --stdin, jusqu'à 16 MiB. Le programme s'exécute dans l'environnement du démon : les préfixes comme NAME=value gh ... sont refusés ; utilisez les arguments du programme. Les arguments développés seulement à l'exécution ($var, jokers) ne peuvent pas être vérifiés par les règles ; le hook demande d'abord confirmation. Le hook autorise directement uniquement les commandes composées entièrement d'appels au programme lié ; si d'autres programmes s'exécutent ou des fichiers sont écrits, la confirmation habituelle de Claude Code s'applique. Si les processus d'arrière-plan laissés par le programme lié gardent les pipelines de sortie ouverts, le nombre de threads lisant ces pipelines est limité ; au-delà, les nouvelles exécutions liées sont refusées. Les règles de permissions deny / ask de Claude Code restent actives, mais peuvent voir la commande réécrite : inscrivez les sous-commandes sensibles dans les règles de liaison. Le programme lié s'exécute hors du verrou du service ; un long gh run watch ne bloque pas les autres clients, mais la limite de 5 minutes reste applicable.

Limiter les hôtes autorisés pour un identifiant et faire émettre par le démon une requête HTTPS ne retournant que le code d'état :

memories credential allow-host VAULT_ID CREDENTIAL_ID api.example.com
memories credential http VAULT_ID CREDENTIAL_ID https://api.example.com/status

credential http utilise uniquement le port HTTPS 443, ne suit pas les redirections et n'hérite pas des proxies.

Les fiches protégées lisent aussi les secrets par saisie masquée, sans les placer dans les arguments :

memories card account VAULT_ID --title "示例邮箱" --email user@example.test --smtp smtp.example.test
memories card env VAULT_ID ./app.env --title "应用配置"
memories card token VAULT_ID --title "API 会话" --host api.example.test
memories card token VAULT_ID --title "浏览器会话" --host app.example.test --cookie
memories card request VAULT_ID TOKEN_CARD_ID https://api.example.test/session
memories card otp VAULT_ID --title "示例 OTP" --issuer Example --account user@example.test
memories card otp VAULT_ID --title "示例 HOTP" --issuer Example --account user@example.test --hotp --counter 0
memories card otp-import VAULT_ID --title "导入的 OTP" "otpauth://totp/Example:user@example.test?secret=GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ&issuer=Example"
memories card otp-import VAULT_ID --image ./ga-export.png --title "GA import"
memories card otp-code VAULT_ID OTP_CARD_ID

Le SMTP des comptes utilise par défaut SSL sur le port 465, ajustable avec --port et --no-ssl. Cela enregistre uniquement la configuration et n'envoie aucun courriel. --cookie conserve la fiche de jeton sous forme d'en-tête Cookie. --method de card request vaut GET par défaut et accepte seulement GET ou POST. OTP accepte --algorithm sha1|sha256|sha512, --digits et --period. --hotp choisit HOTP ; --counter définit le compteur initial, 0 par défaut ; TOTP ignore le compteur. otp-import accepte une URI en argument ; sans URI ni --image, il lit une ligne de l'entrée standard. Un compte unique utilise otpauth://. Le type totp ou hotp de l'URI est détecté automatiquement ; sans type, la présence de counter signifie HOTP, sinon TOTP. La migration Google Authenticator utilise otpauth-migration://offline?data=... et peut créer plusieurs fiches à la fois. --image PATH décode le premier code QR otpauth:// ou otpauth-migration:// d'une image et est incompatible avec une URI. --title est facultatif : il sert de titre pour une seule fiche ou de préfixe pour plusieurs ; sans cette option, le titre est « Émetteur / Compte ». --id peut remplacer une seule fiche et ne convient pas à une migration contenant plusieurs comptes. otp-code retourne un code de courte durée, jamais la graine ; le résultat HOTP inclut le compteur suivant. Le secret ci-dessus est un vecteur de test RFC public : ne le remplacez pas par une vraie graine.

Ajoutez --id CARD_ID pour remplacer une fiche protégée existante. L'identifiant de l'identifiant secret et les liens de fiches sont conservés ; --alias / --notes / --category non fournis restent inchangés, et une chaîne vide les efface. Un card put ordinaire ne peut pas remplacer une référence protégée. Vous pouvez conserver le titre OTP issuer / account et enregistrer séparément le nom affiché dans l'alias et les notes.

Protéger un secret apparaissant exactement une fois dans le corps d'un document. L'étiquette comprend de 1 à 64 lettres ASCII, chiffres, traits de soulignement ou traits d'union et ne doit pas encore être utilisée dans ce document :

memories memory protect-secret VAULT_ID DOCUMENT_ID API_KEY
memories card protect-secret VAULT_ID CARD_ID API_KEY
memories credential copy VAULT_ID DOCUMENT_ID --label API_KEY
memories credential copy VAULT_ID CREDENTIAL_ID

protect-secret demande la saisie du secret. Pour copier une référence de document, --label est obligatoire. Le résultat contient uniquement "copied": true. Windows utilise le presse-papiers système, macOS pbcopy, et Linux nécessite wl-copy sous Wayland ou xclip sous X11. Les fiches protégées de comptes, jetons, environnements et OTP peuvent aussi être copiées directement ; pour OTP, la copie concerne la graine, pas le code à usage unique.

Sur mobile, les options « Fiche protégée », « Importer .env » et « Importer des identifiants de connexion (CSV) » sont disponibles ; vous pouvez aussi coller une URI otpauth:// pour importer TOTP ou HOTP. Les options « Remplacer les clés dans les données » et « Copier la clé » du menu du document correspondent aux opérations ci-dessus. « Générer OTP » produit un code à usage unique. Le mobile ne propose pas d'import de codes QR OTP par caméra ; utilisez la CLI ci-dessus pour les images OTP et URI de migration. Le scan d'appairage d'appareils hébergés suit un autre parcours ; voir Secrets de bout en bout entre appareils.

Importer et exporter des identifiants de connexion aux sites web

Les connexions aux sites web sont conservées dans des fiches protégées login, avec adresse du site et nom d'utilisateur publics, et mot de passe sous forme d'identifiant secret indépendant. Elles sont généralement importées/exportées par lots. L'import et l'export nécessitent tous deux memories sudo et un rôle autorisant l'écriture :

memories sudo
# 浏览器 CSV（Chrome/Edge/Brave，或 Firefox 的 about:logins）；自动识别表头。
memories login import VAULT_ID --from chrome passwords.csv
memories login import VAULT_ID --from firefox firefox-logins.csv --with-notes
# 直接读取 Firefox 配置文件（现代 key4.db，会提示输入主密码，没有则留空）。
memories login import VAULT_ID --from firefox-profile "/路径/Profiles/xxxx.default"
# Windows 凭据管理器的通用凭据（仅 Windows）。
memories login import VAULT_ID --from windows --filter github
memories login import VAULT_ID --from windows --all
# 之前导出的加密文件。
memories login import VAULT_ID --from memories logins.mlx

# 导出：便携加密文件（推荐）或浏览器兼容的 CSV。
memories login export VAULT_ID --format encrypted logins.mlx
memories login export VAULT_ID --format csv logins.csv

Une ligne est ignorée si l'hôte du site, le nom d'utilisateur et le mot de passe correspondent à une fiche existante. Un mot de passe différent est signalé comme conflit et crée une autre fiche ; seul --update remplace la fiche existante. Les lignes CSV invalides sont ignorées et signalées avec leur numéro ; chaque import est limité à 2000 entrées. La colonne note des navigateurs est importée uniquement avec --with-notes, car les notes entrent dans l'index de texte ordinaire. La lecture directe de Firefox prend en charge le format de clé moderne, Firefox 58 et versions ultérieures ; pour les profils plus anciens, exportez un CSV depuis about:logins. Lire les mots de passe enregistrés du navigateur ne modifie pas son stockage.

L'export chiffré utilise un mot de passe distinct et peut être importé dans n'importe quel coffre. L'export CSV est en clair, pour réimporter les connexions dans un navigateur ou un autre gestionnaire de mots de passe. Réservé à la CLI locale, il affiche d'abord un avertissement, écrit dans un fichier accessible uniquement au propriétaire et qui ne doit pas déjà exister, et protège contre l'injection de formules les cellules commençant par = + - @. Supprimez-le après usage. Les coffres réservés à cet appareil ne peuvent pas être exportés.

Sessions distantes et proxies de boucle locale

Autorisez d'abord l'hôte cible avec credential allow-host. Pour SSH, récupérez aussi l'empreinte de clé d'hôte par la sonde et vérifiez-la via un canal fiable :

memories remote probe example.test --port 22
memories remote open ssh --vault VAULT_ID --credential KEY_ID --host example.test --user alice --host-key HOST_KEY
memories remote open ssh --vault VAULT_ID --credential KEY_ID --certificate CERT_ID --host example.test --user alice --host-key HOST_KEY
memories remote sessions
memories remote run SESSION_ID -- uname -a
memories remote propose SESSION_ID -- uname -a
memories remote approve TICKET_ID
memories remote exec TICKET_ID
memories remote close SESSION_ID

remote run enchaîne proposition, approbation interactive et exécution. Pour séparer ces étapes dans un script, remote propose met en attente et retourne un ticket ; remote approve approuve avec sudo, le ticket n'étant utilisable qu'une fois ; puis le même appelant disposant d'une élévation exécute remote exec.

Les bases de données activent TLS et la vérification du nom d'hôte par défaut. --tls-ca CA_ID ajoute une autorité PEM du coffre. --no-tls désactive explicitement TLS. --database désigne le nom de base MySQL/PostgreSQL ou l'index de base logique Redis :

memories remote open mysql --vault VAULT_ID --credential CREDENTIAL_ID --host db.example.test --user app --database appdb
memories remote open postgres --vault VAULT_ID --credential CREDENTIAL_ID --tls-ca CA_ID --host db.example.test --user app --database appdb
memories remote open redis --vault VAULT_ID --credential CREDENTIAL_ID --host redis.example.test --user default
memories remote run SESSION_ID --op query -- SELECT 1

remote open accepte les protocoles ssh, ftp, tcp, mysql, redis, postgres. FTP utilise des opérations de fichiers ; SSH et les sessions de base de données utilisent exec ou query. Chaque instruction est d'abord proposée puis approuvée. remote run enchaîne proposition, approbation interactive et exécution. Le mot d'approbation est APPROVE. MCP ne peut ni ouvrir ni approuver de sessions distantes.

Le proxy de boucle locale écoute sur 127.0.0.1. Le champ command retourné peut être exécuté dans un terminal de la machine du démon, sans contenir le mot de passe ou la clé privée enregistrés :

memories proxy start ssh --vault VAULT_ID --credential KEY_ID --host example.test --user alice --host-key HOST_KEY
memories proxy start postgres --vault VAULT_ID --credential PASSWORD_ID --host db.example.test --user app --database appdb
memories proxy start mysql --vault VAULT_ID --credential PASSWORD_ID --host db.example.test --user app --database appdb
memories proxy start redis --vault VAULT_ID --credential PASSWORD_ID --host cache.example.test --user default
memories proxy list
memories proxy stop PROXY_ID

Les protocoles de proxy sont uniquement ssh, mysql, redis, postgres. --listen-port est facultatif ; 0 laisse le système choisir le port. --certificate, --tls-ca, --tls et --no-tls sont facultatifs. Tout processus pouvant joindre ce port local peut utiliser le compte distant déjà autorisé. Le verrouillage, le verrouillage du coffre après inactivité, proxy stop et la sortie du démon ferment l'écoute et les connexions existantes. Un proxy dure au maximum 30 minutes ; il peut y avoir au plus quatre proxies, chacun limité à 16 connexions. MCP ne peut ni démarrer, ni lister, ni arrêter des proxies.

Exécuter des tâches cryptographiques

Les outils de courriel et de signature doivent être installés séparément. Importez l'identité et le mot de passe comme deux identifiants distincts. --credential, --password_id et --key-password désignent des identifiants d'identifiants secrets, pas les secrets eux-mêmes. --password et --password-id sont des alias de --password_id.

Commencez avec --dry-run. Cette option lit l'entrée et les outils, affiche le plan et le digest approval, sans démon ni écriture de fichier de sortie. Après confirmation, exécutez sudo dans le même terminal, puis la même commande sans --dry-run. Pour une exécution non interactive, fournissez --approve-digest DIGEST. La sortie doit être un nouveau chemin dans un répertoire existant.

S/MIME utilise OpenSSL. Ajoutez --pkcs12 pour une identité PKCS#12. Le chiffrement utilise seulement la clé publique du destinataire : ne fournissez pas d'identifiant d'identité :

memories crypto smime-sign --vault VAULT_ID --input message.eml --output signed.eml --credential IDENTITY_ID --password_id PASSWORD_ID --pkcs12 --tool openssl=/path/to/openssl --dry-run
memories crypto smime-encrypt --vault VAULT_ID --input signed.eml --output encrypted.eml --recipient recipient.pem --tool openssl=/path/to/openssl --dry-run
memories crypto smime-decrypt --vault VAULT_ID --input encrypted.eml --output decrypted.eml --credential IDENTITY_ID --password_id PASSWORD_ID --pkcs12 --tool openssl=/path/to/openssl --dry-run

OpenPGP nécessite la paire gpg et gpgconf. --identity est l'empreinte complète. Pour la version MSYS de GnuPG fournie avec Git for Windows, ajoutez --msys-gpg :

memories crypto pgp-sign --vault VAULT_ID --input message.eml --output message.sig.asc --credential KEY_ID --password_id PASSWORD_ID --identity FULL_FINGERPRINT --tool gpg=/path/to/gpg --tool gpgconf=/path/to/gpgconf --dry-run
memories crypto pgp-encrypt --vault VAULT_ID --input message.eml --output message.eml.asc --recipient recipient.asc --identity FULL_FINGERPRINT --tool gpg=/path/to/gpg --tool gpgconf=/path/to/gpgconf --dry-run
memories crypto pgp-decrypt --vault VAULT_ID --input message.eml.asc --output decrypted.eml --credential KEY_ID --password_id PASSWORD_ID --tool gpg=/path/to/gpg --tool gpgconf=/path/to/gpgconf --dry-run

La signature Android ne crée pas de paquet d'installation et ne contacte pas de boutique d'applications. Le chemin d'apksigner est lib/apksigner.jar dans le SDK :

memories crypto android-apk --vault VAULT_ID --input unsigned.apk --output signed.apk --credential KEYSTORE_ID --password_id STORE_PASSWORD_ID --identity release --tool java=/jdk/bin/java --tool zipalign=/sdk/build-tools/35.0.0/zipalign --tool apksigner=/sdk/build-tools/35.0.0/lib/apksigner.jar --dry-run
memories crypto android-bundle --vault VAULT_ID --input unsigned.aab --output signed.aab --credential KEYSTORE_ID --password_id STORE_PASSWORD_ID --identity release --tool jarsigner=/jdk/bin/jarsigner --dry-run

Si le mot de passe de la clé diffère de celui du magasin, utilisez --key-password KEY_PASSWORD_ID.

La signature iOS est disponible uniquement sur macOS. L'entrée est une .app contenant déjà un embedded.mobileprovision correspondant :

memories crypto ios-app --vault VAULT_ID --input Unsigned.app --output Signed.app --credential APPLE_P12_ID --password_id PASSWORD_ID --identity CERTIFICATE_SHA1 --entitlements App.entitlements --tool openssl=/path/to/openssl --tool security=/usr/bin/security --tool codesign=/usr/bin/codesign --dry-run

Ces commandes n'envoient pas de courriels et ne publient pas d'applications. MCP et le client mobile ne peuvent pas les exécuter.

Appairer les appareils, synchroniser et sauvegarder

L'appairage ajoute le nouvel appareil d'une même personne à une identité existante ; l'invitation d'un membre attribue un rôle dans un coffre à une autre personne. Les deux utilisent des fichiers de demande et d'approbation, sans être interchangeables.

Le nouvel appareil commence par init avec son propre mot de passe et ne doit posséder aucun coffre avant son rattachement. Ensuite :

memories sudo
memories device invite request.json

Transmettez le fichier de demande à l'appareil existant. Vérifiez l'empreinte complète de l'invitation affichée sur l'appareil demandeur avant d'approuver. La commande d'approbation retourne la clé publique de l'appareil approbateur ; vérifiez-la par un canal fiable avant l'acceptation sur le nouvel appareil :

memories sudo
memories device approve request.json approval.json --fingerprint REQUEST_FINGERPRINT

Sur le nouvel appareil, relancez sudo dans le terminal qui exécutera l'acceptation, puis acceptez l'approbation et vérifiez la liste des appareils :

memories sudo
memories device accept approval.json --sender APPROVING_DEVICE_PUBLIC_KEY
memories device list

La demande expire après 10 minutes et n'est utilisable qu'une fois.

Approuver l'adhésion d'une autre personne à un coffre :

memories member approve VAULT_ID request.json approval.json --fingerprint REQUEST_FINGERPRINT --role reader
memories member list VAULT_ID
memories member role VAULT_ID USER_PUBLIC_KEY editor
memories member remove VAULT_ID USER_PUBLIC_KEY
memories member transfer VAULT_ID USER_PUBLIC_KEY
memories device revoke VAULT_ID DEVICE_PUBLIC_KEY

--role de l'approbation d'invitation et l'argument de rôle de member role doivent être admin, editor ou reader, dans les limites des permissions de l'opérateur : le propriétaire gère les administrateurs ; les administrateurs ne peuvent gérer que les lecteurs et éditeurs ordinaires ; les éditeurs peuvent écrire, les lecteurs lire et utiliser. Bien que la CLI accepte owner, la politique du coffre exige exactement un propriétaire : une invitation ou un changement de rôle ordinaire ne peut pas en ajouter. Pour transférer la propriété, le propriétaire actuel exécute memories member transfer VAULT_ID USER_PUBLIC_KEY, avec un membre existant comme cible ; l'ancien propriétaire devient administrateur. La révocation d'un appareil doit être effectuée dans chaque coffre concerné. Retirer un membre n'efface pas les copies qu'il possède déjà.

Échange de fichiers sans relais :

memories sync export VAULT_ID RECIPIENT_DEVICE_PUBLIC_KEY packet.json
memories sync import packet.json

Pour un transfert en ligne, lancez d'abord memories-relay derrière un proxy inverse TLS, puis générez un numéro de salle avec sync room. Le destinataire attend avant que l'expéditeur envoie :

memories sync room
memories sync receive --relay wss://relay.example.com --room ROOM
memories sync send VAULT_ID RECIPIENT_DEVICE_PUBLIC_KEY --relay wss://relay.example.com --room ROOM

Les relais distants acceptent uniquement wss://. ws:// est réservé aux adresses locales de développement. L'URL ne peut contenir ni nom d'utilisateur ni mot de passe. relay_url dans la configuration fournit l'adresse par défaut ; --relay dans la commande la remplace. La valeur par défaut de --slot est a à l'envoi et b à la réception. Un envoi réussi signifie seulement que le paquet a été remis au relais, pas qu'il a été importé par l'autre partie. Le relais ne met rien en attente pour les appareils hors ligne. sync export/import et sync send/receive via relais sont des transferts explicites du coffre entier, pas une synchronisation d'objets cloud ni du RPC distant.

Consulter la quarantaine, resigner les révisions d'anciennes époques dans l'époque actuelle et conserver la branche de politique locale lorsque les identités de propriétaire des deux parties sont valides :

memories sync quarantine VAULT_ID
memories sync reapply VAULT_ID REVISION
memories sync resolve-policy VAULT_ID packet.json --keep-local

Les comptes cloud utilisent une application OAuth que vous avez vous-même enregistrée. Déverrouillez le stockage et exécutez sudo dans le même terminal avant la connexion :

memories cloud login onedrive --client-id YOUR_MICROSOFT_CLIENT_ID
memories cloud login google-drive --client-config /path/to/google-desktop-client.json
memories cloud status
memories cloud sync onedrive
memories cloud logout onedrive

cloud login accepte --no-browser et --port. 0 sélectionne automatiquement le port de rappel local. L'état n'affiche pas de jetons. La déconnexion supprime uniquement l'autorisation locale. cloud sync actualise les jetons et téléverse/télécharge des données chiffrées immuables via le dossier d'application OneDrive ou Google Drive connecté. Le client mobile propose la connexion cloud et la synchronisation au premier plan. La validation de bout en bout avec de vrais comptes OneDrive et Google Drive n'est pas encore terminée. La synchronisation mobile en arrière-plan n'est pas activée. Ne placez pas le répertoire de base de données dans un dossier synchronisé par un client de disque cloud.

Audit et sauvegardes hors ligne :

memories audit VAULT_ID --verify
memories sudo
memories audit VAULT_ID
memories backup offline-backup.memories

La restauration doit utiliser un nouveau répertoire de données, avec un démon démarré dans ce répertoire :

memories --home NEW_DIRECTORY restore offline-backup.memories --name replacement
memories --home NEW_DIRECTORY sudo
memories --home NEW_DIRECTORY archive list
memories --home NEW_DIRECTORY archive history VAULT_ID
memories --home NEW_DIRECTORY archive read VAULT_ID REVISION
memories --home NEW_DIRECTORY archive audit VAULT_ID

La restauration crée un coffre indépendant contenant les actifs courants et les heads en conflit. Les versions originales, tombstones et audits signés restent dans une archive en lecture seule. Les valeurs historiques d'identifiants ne peuvent pas être affichées via les interfaces ordinaires ou d'archive. Les coffres propres à un appareil et les jetons cloud ne sont pas sauvegardés.

Ouvrir l'interface d'état du bureau

Dans le paquet Windows, double-cliquez sur memories-tray.exe situé à côté de memories.exe. Sur macOS, ouvrez Memories.app fournie dans le paquet. Dans un terminal :

memories tray
memories webui
memories --home /path/to/development-home webui --no-open --port 0
memories webui --open
memories-tray --home /path/to/development-home --no-open

tray ouvre la zone de notification ou la barre de menus native, avec une page d'état. webui ouvre uniquement le tableau de bord dans le navigateur et reste au premier plan. --port 0 sélectionne un port de boucle locale disponible. --no-open n'ouvre pas automatiquement le navigateur. --open l'ouvre même si la configuration désactive l'ouverture automatique. --config et --lang s'appliquent aussi à ces deux commandes et à memories-tray.

La zone de notification peut indiquer hors ligne, initialisation nécessaire, verrouillé ou déverrouillé, et peut démarrer le démon. Elle n'initialise pas, ne déverrouille pas et n'accorde pas d'élévation. La page d'état s'actualise environ toutes les deux secondes et affiche le nombre de coffres, de proxies et de sessions distantes, les types de fournisseurs cloud configurés, et les compteurs de téléversement, téléchargement et synchronisation en attente. Elle n'affiche ni contenu, noms de coffres, identifiants, comptes, chemins ni jetons. Quitter la zone de notification ou interrompre webui au premier plan arrête uniquement cette page d'état, sans arrêter le démon déjà lancé.

Sous Linux, utilisez memories webui. Linux n'a pas de zone de notification native et le paquet Linux ne contient pas de lanceur de zone de notification.

Accorder MCP et installer un skill d'IA

Cette section présente d'abord MCP ordinaire : accordez à un client d'IA des capacités pour un coffre, une durée et un périmètre d'opérations, sans héritage du sudo du terminal. L'autorisation est écrite dans un fichier, jamais affichée ; ce fichier est lui-même un justificatif bearer à protéger. Le périmètre par défaut est en lecture seule. --scope read_write autorise lecture et écriture des données ordinaires ; --scope read_write_delete ajoute la suppression ; --write est un raccourci compatible de read_write. La durée est définie avec --minutes, ici 15 minutes :

memories sudo
memories mcp grant VAULT_ID PRIVATE_GRANT_FILE --minutes 15
memories mcp serve --grant-file PRIVATE_GRANT_FILE
memories mcp revoke PRIVATE_GRANT_FILE

Configurez la commande MCP stdio du client d'IA sur memories mcp serve --grant-file ..., avec le même répertoire de données que le démon. Les outils sont memory_search, memory_retrieve, memory_ask, memory_read, memory_read_revision, memory_history, memory_diff, memory_write, memory_delete, card_write, card_graph, card_link, workflow_card, workflow_read, workflow_update et workflow_list, ainsi que les outils persona répertoriés dans le guide des fiches persona en anglais. workflow_card crée des workflows à étapes, modèles de listes ou tâches copiées d'un modèle ; workflow_update modifie les champs de liste ou fait avancer les étapes. Les deux nécessitent l'écriture ; workflow_read et workflow_list nécessitent seulement la lecture. Chaque appel inclut l'identifiant du coffre autorisé. memory_retrieve utilise BM25 local par défaut ; vector et hybrid utilisent le fournisseur d'embeddings configuré dans le démon. memory_ask répond lorsqu'une adresse de génération est configurée et refuse les citations absentes des preuves récupérées.

MCP ordinaire exclut les mémoires privées, fichiers, identifiants, exécutions de processus, sessions distantes, proxies, tâches cryptographiques, gestion des membres et état du bureau. Même --scope allow_all ne franchit pas cette frontière. La délivrance, la liste et la révocation d'autorisations, ainsi que les demandes de permissions, utilisent d'autres outils MCP, toujours sans héritage de sudo. Le verrouillage rend temporairement ces autorisations indisponibles ; celles non expirées redeviennent disponibles après déverrouillage. La version du protocole est 2024-11-05. Les fiches contenant des références secrètes ne peuvent pas être modifiées avec le card_write actuel, car cet outil ne conserve pas la table de références ; utilisez la CLI ou le mobile.

Pour la lecture sans surveillance, consultez séparément CLI/MCP sans surveillance. Ce parcours impose de choisir explicitement un backend de garde des clés, de saisir ENABLE et de terminer l'autorisation par mot de passe, puis de créer un fichier client limité à un coffre. Utilisez mcp serve-unattended --client-file PATH, distinct de mcp serve ordinaire. Cet accès est local et en lecture seule, mais inclut les données privées, fichiers originaux, historiques et identifiants en clair explicitement demandés, sans héritage de sudo. Le client d'IA et ses journaux peuvent conserver les secrets ; Base64 n'est pas du chiffrement. Un verrouillage manuel bloque durablement cet accès jusqu'à unattended resume autorisé par mot de passe. Les transports distants, le mobile et les stockages gérés par Center ne peuvent pas l'utiliser.

memories unattended enable --backend windows-dpapi
memories unattended mint --vault VAULT_ID --client-file /private/dir/client.json
memories unattended list VAULT_ID --client-file /private/dir/client.json
memories unattended history VAULT_ID ASSET_ID --client-file /private/dir/client.json
memories unattended read VAULT_ID ASSET_ID --client-file /private/dir/client.json
memories unattended credential-bytes VAULT_ID CREDENTIAL_ID --client-file /private/dir/client.json
memories mcp serve-unattended --client-file /private/dir/client.json
memories unattended status
memories unattended resume
memories unattended revoke GRANT_ID
memories unattended disable

Les backends disponibles sont windows-dpapi, macos-keychain, linux-secret-service ou owner-file, moins protecteur et nécessitant un choix explicite. Le répertoire du fichier client doit déjà exister et être accessible uniquement au propriétaire ; mint n'écrase pas de fichier existant. read et credential-bytes retournent des segments d'octets en base64url : commencez par --offset 0, utilisez à chaque fois le next de la réponse précédente comme nouvel --offset, et fixez avec --revision la révision retournée au premier appel, jusqu'à ce que next soit null ; concaténez ensuite dans l'ordre les octets décodés. list / history retournent au plus 100 éléments par page. status, resume, revoke et disable nécessitent un terminal déverrouillé avec sudo actif.

Installer le skill fourni avec le programme. L'installation n'ouvre pas le stockage et ne configure pas MCP :

memories inject all --dry-run
memories inject all
memories inject codex
memories inject opencode claude
memories inject all --project /path/to/project

all inclut Codex, OpenCode et Claude Code. claude-code est un alias de claude. --project installe dans un répertoire de projet existant. Après une mise à niveau de la CLI, utilisez --force pour remplacer les contenus installés auparavant qui diffèrent :

memories inject all --force

--force remplace uniquement SKILL.md. Un contenu identique reste intact. Les liens vers les fichiers ou répertoires de skills sont refusés.

Générer pour un projet un AGENTS.md expliquant l'utilisation de Memories, ou un répertoire de skill de style Cursor/Codex, avec éventuellement le résumé du noyau d'une fiche persona intégré. agents est un alias de skill :

memories skill generate --out AGENTS.md
memories skill generate --out AGENTS.md --persona VAULT/PERSONA
memories agents generate --out ./skills/memories-persona --layout skill --persona VAULT/PERSONA

--layout agents, par défaut, écrit un fichier Markdown ; --layout skill écrit SKILL.md dans le répertoire de sortie, ou directement le fichier indiqué si le chemin se termine déjà par .md. Sans --persona, la persona des valeurs par défaut du client est utilisée. Avec une persona, la génération lit la fiche via le démon et nécessite un déverrouillage préalable ; sans persona, elle fonctionne hors ligne et sans démon. --force remplace un fichier existant dont le contenu diffère ; --dry-run prévisualise sans écrire.

Valeurs par défaut du client

Les valeurs par défaut non secrètes de la ligne de commande sont enregistrées dans defaults.json sous le répertoire de données (--home / MEMORIES_HOME), en dehors du contenu chiffré du coffre :

memories default set persona VAULT/PERSONA
memories default set vault VAULT_ID
memories default set type persona
memories default get
memories default get type
memories default delete type

Les arguments explicites ont toujours priorité. Les sous-commandes persona acceptant un coffre et un actif (world-get, thing, append-event, etc.) utilisent les valeurs par défaut pour les arguments positionnels omis ; persona import exige toujours l'identifiant du coffre avant le chemin du skill.

Centre d'autorisation (Center)

Center est un plan de contrôle d'autorisation externe qui distribue aux clients des tickets d'enregistrement et de capacité. Dès que la configuration contient un [[centers]], le client est géré par Center : l'amorçage local init / restore et les autorisations MCP locales sont interdits et remplacés par les tickets délivrés par Center. Le coffre se déverrouille toujours localement avec le mot de passe de l'appareil ; Center n'obtient ni clés de coffre ni secrets en clair. Les jetons d'écoute, clés de signature Center et jetons d'administration ne sont pas écrits dans TOML.

# 管理员：生成写入配置的公钥并签发票据（或使用 memories-center HTTP 服务）
export MEMORIES_CENTER_SECRET="…"   # 32 字节，URL 安全 base64 或 64 位十六进制
memories center public-key
memories center issue-bootstrap --center corp --device-name laptop
memories center issue-grant --center corp --vault VAULT_ID --scope read --minutes 15

# 终端（守护进程已按含 centers 的配置运行）
memories center list
memories center enroll --ticket "$BOOTSTRAP_TICKET"
memories sudo
memories center import-grant --ticket "$GRANT_TICKET"

Pour les périmètres (read, write, read_write, read_write_delete, allow_all et leurs alias), le format de configuration et le modèle de menace, voir Centre d'autorisation en anglais.

Coffres hébergés (SaaS)

memories-center --data DIR, ou la variable d'environnement MEMORIES_CENTER_DATA, permet à Center d'exploiter des coffres entièrement hébergés : le serveur conserve le Store chiffré avec un mot de passe détenu par l'opérateur et réutilise les mêmes interfaces de service que le démon. L'unique entrée mode = "saas" de la configuration place le démon local en mode SaaS, où ce Center contrôle les opérations de contenu, avec le jeton de MEMORIES_CENTER_TOKEN. Les administrateurs peuvent verrouiller/déverrouiller à distance via /v1/admin/lock, /v1/admin/unlock, et gérer les membres via /v1/admin/members. Les données hébergées sont visibles par l'opérateur et ne sont pas chiffrées de bout en bout. Les métadonnées des demandes sont conservées dans DIR/requests.json et l'audit à chaîne de hachage dans DIR/audit.jsonl.

Chaîne d'autorisation

Les rôles de coffre sont Owner, Admin, Editor, Reader. Seuls Admin et les rôles supérieurs peuvent délivrer ou déléguer une autorisation. La délivrance nécessite seulement un coffre déverrouillé, sans élévation du terminal ; l'approbation de demandes de rôle nécessite une élévation. Le périmètre ne dépasse pas le rôle de l'émetteur ni l'autorisation parente ; le bénéficiaire ne peut pas avoir un rôle supérieur à l'émetteur, et center-admin ne peut pas être bénéficiaire. La profondeur de délégation est limitée à 2 niveaux. Sans périmètre explicite, la valeur par défaut est read, et non allow_all. Le démon local et le Center hébergé acceptent chacun au maximum 10000 autorisations actives simultanées.

Les demandes de permissions peuvent être diffusées à tous les approbateurs éligibles, ou adressées à un approbateur avec --approver. Elles peuvent être approuvées ou refusées, mais personne ne peut décider de sa propre demande. L'approbation ne retourne pas de jeton : le demandeur doit le récupérer une seule fois avec memories request claim VAULT ID, memories center request claim ID, MCP request_claim ou POST /v1/requests/{id}/claim. Chaque demandeur est limité à 20 demandes en attente par coffre, chaque coffre à 200 ; Center retourne HTTP 429 au-delà. Les demandes en attente ou approuvées mais non récupérées expirent après 7 jours ; les demandes terminées sont conservées 30 jours.

memories access list VAULT          # 按级别列出成员、设备、待处理与已批准未领取的请求
memories grant list VAULT
memories request create VAULT --scope read --approver MEMBER_ID
memories request approve VAULT ID
memories request claim VAULT ID

Le retrait d'un membre révoque en cascade les autorisations qu'il a délivrées, par invalidation des générations de membre. Seuls les hachages des autorisations sont persistés ; le journal d'audit forme une chaîne de hachage. Voir Autorisation en anglais.

Choisir la langue

Le mobile propose un menu de langue sur l'écran de verrouillage et dans le coffre. Par défaut, il suit le système ; un choix manuel est conservé après redémarrage.

La priorité de la CLI est --lang, MEMORIES_LANG, la langue enregistrée, puis la première valeur non vide parmi LC_ALL, LC_MESSAGES et LANG. Sous Windows, si ces variables sont absentes, la langue du système est également consultée. Une locale inconnue revient à l'anglais. zh-CN et fr_FR.UTF-8 sont reconnus.

memories --lang zh --help
memories language zh
memories language
memories language system

Sans argument après language, la commande affiche la langue enregistrée et celle actuellement effective. system efface le choix et rétablit le suivi du système. La langue enregistrée dépend de --home et ne nécessite pas de démon. Les noms de commandes et d'options, champs JSON, codes d'erreur, USE et APPROVE ne sont pas traduits. Le contenu utilisateur n'est pas traduit non plus.

Démon distant (HTTP/WebSocket / RPC via relais)

L'écoute HTTP/WebSocket facultative authentifiée par jeton et le RPC via relais WSS utilisent les mêmes trames JSON binaires WebSocket, AuthFrame suivi de Wire, conformément au protocole local IPC service::Request. Le RPC exécute les commandes sur le stockage de l'hôte distant, sans créer de copie du coffre chez l'appelant. Utilisez sync pour échanger des copies ; utilisez cloud sync PROVIDER pour synchroniser via une file persistante d'objets cloud OneDrive/Google Drive. Qu'il transporte du RPC ou des coffres entiers, le relais n'est pas un dépôt d'actifs hors ligne. Le jeton d'écoute doit être fourni uniquement par une option ou une variable d'environnement, jamais dans TOML. HTTP/WS en clair, par défaut, ne nécessite pas de certificat ; activez HTTPS/WSS avec --tls-cert / --tls-key si nécessaire. Après déverrouillage/élévation à distance, le démon de bureau offre toutes les opérations de l'IPC local, avec les espaces d'élévation ws:remote / relay:remote ; Share sur mobile respecte toujours la liste de refus FFI. Voir remote-daemon.md.

Le relais peut aussi transmettre les webhooks d'automatisation persona : POST /v1/persona/{room}/{vault}/{persona}/automation/trigger, avec les mêmes corps et jetons webhook que le démon. Il les transmet seulement à l'hôte connecté et n'émet aucun POST sortant.

Options TLS globales : --ca-file PATH (MEMORIES_CA_FILE) ajoute une autorité PEM aux clients TLS sortants ; --insecure ignore la vérification du certificat et du nom d'hôte tout en conservant TLS. Uniquement pour le développement ou les certificats autosignés ; préférez --ca-file.

memories daemon --listen http://127.0.0.1:7900 --listen-token "$TOKEN"
export MEMORIES_DAEMON=http://127.0.0.1:7900
export MEMORIES_DAEMON_TOKEN="$TOKEN"
memories status

Choix et changement de mode sur mobile

Choisissez un mode au premier lancement ; la page de choix apparaît aussi après une mise à niveau depuis une version sans réglage de mode. L'application mémorise ce choix et ouvre directement le mode correspondant la fois suivante.

Le mode Center désigne ici un service hébergé sur votre propre serveur, qui doit activer memories-center --data DIR. Il diffère du Center d'autorisation délivrant uniquement des tickets d'appareil et de permissions. Sur mobile, il n'est pas nécessaire de modifier config.toml, de définir mode = "saas" ou de déverrouiller d'abord le stockage local ; ces réglages TOML concernent le démon de bureau.

Pour Center, indiquez uniquement l'origine du serveur, par exemple https://center.example.com, sans /v1/rpc, paramètres de requête, nom d'utilisateur ou mot de passe. Toute adresse hors boucle locale doit utiliser HTTPS ; localhost sur le téléphone désigne le téléphone lui-même. Le jeton de membre est fourni par l'opérateur du service ; ses opérations possibles dépendent du coffre, du rôle, du périmètre et de sa validité. Le jeton d'administration de l'opérateur ne peut pas remplacer directement un jeton de membre pour lire/écrire du contenu.

Changer de mode pendant l'utilisation

La double flèche en haut de l'écran principal correspond à « Changer de mode », avant ou après connexion. La fenêtre indique le mode courant ; sélectionner un autre mode effectue le changement, annuler conserve la session actuelle. Dans un éditeur, enregistrez ou quittez d'abord ; un contenu non enregistré demande confirmation.

Changer de mode ne téléverse, déplace, fusionne ou supprime aucune donnée du coffre. Déconnecter ne révoque pas le jeton côté serveur. Les adresses et jetons Center et SaaS sont conservés séparément dans le stockage sécurisé du système ; les anciennes connexions sont migrées uniquement vers leur mode correspondant : l'adresse SaaS officielle vers SaaS, toutes les autres vers Center.

Fonctionnalités de chaque mode

Le mode autonome conserve la consultation, la recherche, l'édition, la sauvegarde/restauration, le partage et la connexion cloud des données locales. Center / SaaS proposent la liste des connaissances hébergées, la recherche, les détails, l'édition, la création et la suppression, ainsi que l'approbation des demandes d'autorisation et la gestion des appareils appairés. Après connexion, vous pouvez consulter le coffre et le périmètre actuels, puis gérer le contenu dans « Connaissances hébergées ». La création de fiches ne propose pas encore les étiquettes, sources et relations ; l'édition de fiches ordinaires existantes prend en charge ces champs et préserve les autres métadonnées. Les mémoires ordinaires utilisent l'éditeur de contenu ; les configurations structurées, fiches protégées, modèles de types et fiches de bout en bout sont ici consultables seulement et nécessitent un éditeur dédié pour les modifier.

La page d'autorisation comporte « En attente » et « Historique ». Avant approbation ou refus, vous pouvez consulter le demandeur, le coffre, le périmètre, la durée et le motif complet ; une confirmation est requise. Après approbation, le demandeur doit toujours récupérer séparément l'autorisation. L'historique inclut les décisions de cette connexion et les demandes approuvées retournées par le serveur, sans constituer un journal d'audit complet. En cas d'échec de connexion, vérifiez le réseau, les certificats, l'adresse, le jeton de membre et l'activation du stockage hébergé sur votre Center.

Mode hébergé sur mobile (Hosted Center)

La recherche s'exécute côté serveur et exclut le contenu privé, les identifiants et les fichiers. Effacer les mots-clés réaffiche la liste de connaissances ; avec la lecture autorisée, les fiches privées de la liste sont consultables. Les comptes en lecture seule ne voient pas les actions de modification ; les comptes en écriture seule peuvent créer directement. La suppression exige la permission correspondante et une confirmation supplémentaire. Un échec d'enregistrement conserve le brouillon ; les détails ne se ferment qu'après confirmation de la suppression par le serveur. L'enregistrement ne comporte actuellement pas de contrôle atomique de concurrence fondé sur la version attendue : des personnes modifiant simultanément une fiche peuvent écraser leurs derniers champs respectifs.

Lors de la mise à niveau de l'application, mettez aussi à niveau votre Center pour fournir /v1/session. Si la session expire ou est révoquée, déconnectez-vous puis reconnectez-vous avec un jeton valide. Si les permissions sont insuffisantes, contactez l'administrateur du service ; si le service est indisponible ou le coffre verrouillé, réessayez plus tard.

Center et SaaS partagent les interfaces hosted_* de la FFI memories_call : connexion, liste et approbation des demandes, liste d'accès, déconnexion et hosted_rpc limité. La connexion est validée par hosted_status, correspondant à GET /v1/session, qui retourne le coffre, le périmètre, le rôle, l'expiration et les capacités de lecture/écriture/suppression, sans jeton. hosted_rpc prend en charge liste, lecture, recherche, suppression, types de fiches, création de fiches de connaissance, champs et opérations d'identifiants ; put accepte memory, card et credential. La liste complète des opérations autorisées et les interfaces d'appareil figurent dans Interface hébergée mobile. Toutes les opérations FFI n'ont pas nécessairement une page Flutter correspondante.

En mode hébergé, le serveur peut lire les données : le Store est chiffré sur disque, mais l'opérateur détient le mot de passe de déverrouillage et peut lire le contenu hébergé ; l'application affiche la mention « Lisible par le serveur ». Le client Rust conserve les jetons actifs en mémoire ; Flutter utilise le stockage sécurisé du système pour les informations de connexion de chaque mode. Les secrets scellés entre appareils ont une frontière de protection de bout en bout distincte, décrite dans la section suivante.

Synchronisation de secrets de bout en bout (E2E) entre appareils

Le serveur peut lire le contenu ordinaire du Center hébergé. Pour les secrets que le serveur ne doit pas voir, appairez les appareils et envoyez des enveloppes scellées, chiffrées avec X25519 et signées avec la clé Ed25519 de l'expéditeur ; Center ne conserve que des clés publiques et du texte chiffré.

Procédure d'appairage : 1. Ordinateur : memories device hosted init --backend … génère une identité d'appareil dans le système de garde des clés. 2. Ordinateur, avec jeton de membre : memories device hosted pair --vault V. Center crée une demande de permissions incluant l'empreinte de l'appareil et retourne un code d'appairage à usage unique et le contenu du code QR, incluant l'id du Center. Le code expire après 5 minutes. Le code QR affiché dans le terminal sur stderr contient aussi le code à usage unique et peut être scanné par le téléphone ; le JSON stdout reste inchangé. Réappairer un appareil déjà actif retourne 409 ; après révocation, la même clé peut servir à un nouvel appairage. 3. Téléphone, administrateur : saisir/scanner le code d'appairage pour récupérer la clé publique de l'appareil, une seule fois ; trop d'échecs entraîne une limitation de débit. 4. Le téléphone approuve via /v1/requests/{id}/approve et joint une attestation d'appareil signée avec sa clé Ed25519. 5. Ordinateur : memories device hosted claim --request-id ID récupère l'autorisation d'appareil une seule fois. Le jeton est conservé dans le système de garde des clés ; Center ne conserve que son hachage. 6. Comparer le SAS : le téléphone l'affiche avant approbation, groupé par exemple comme 123 456. Après approbation, memories device hosted sas --pairing-id P sur l'ordinateur doit afficher les mêmes chiffres ; sinon, révoquez l'appareil et recommencez l'appairage.

Le scan mobile refuse les codes qui ne sont pas des codes d'appairage Memories, ceux dont l'id du Center ne correspond pas à la connexion actuelle et ceux dont l'empreinte d'appareil diffère. Permissions : Android CAMERA, caméra facultative ; iOS NSCameraUsageDescription. Si l'accès caméra est refusé, le téléphone invite à l'activer dans les réglages du système et permet la saisie manuelle du code. La CLI et le mobile convertissent les codes d'état Center en indications exploitables : 404 expiré/déjà utilisé/autre Center ; 409 déjà traité ou déjà appairé ; 403 accès interdit ou appareil révoqué ; 422 contenu e2e refusé ; 429 trop de demandes.

Définition du SAS : les 8 premiers octets de SHA-256("memories/device-sas/v1\0" ‖ 手机公钥 ‖ "\0" ‖ 电脑公钥 ‖ "\0" ‖ pairing_id) sont convertis en entier big-endian, réduits modulo 10^6 et complétés de zéros pour obtenir 6 chiffres. Une différence indique une substitution de clé publique et exige une révocation immédiate.

Règles : l'autorisation d'appareil est liée à l'appareil et à la génération du membre, avec une profondeur de délégation ≤ 2. Les appareils ne peuvent pas délivrer d'autorisations ni approuver de demandes. Un changement de membre invalide les appareils et supprime leurs enveloppes. Les fiches e2e: true refusent les secrets en clair sur le Center hébergé. La liste d'accès inclut les appareils. MCP fournit device_list et sealed_reveal, qui exige une intention explicite, intent: "reveal_plaintext", et un motif.

Modèle de menace : Center ne peut pas lire les secrets scellés, mais voit les métadonnées et peut retenir des enveloppes. La révocation ne peut pas récupérer le texte en clair déjà remis à un appareil : après révocation, renouvelez ce secret à sa source.

Renforcement E2E (P2)

• Le marqueur e2e ne peut pas être retiré silencieusement : une fois une fiche marquée e2e: true, toute écriture retirant ce marqueur est refusée avec 422. Seule une autorisation Owner, et non une autorisation d'appareil, peut l'effacer par une écriture ne contenant aucun secret.
• Paramètres OTP : un OTP scellé peut être une graine Base32, SHA1/6 chiffres/30 secondes, ou une URI otpauth://totp/... complète. sealed-get --otp respecte algorithm (SHA1/SHA256/SHA512), digits (6/8) et period (30/60). device hosted pair affiche le code QR d'appairage sur stderr dans le terminal.
• Rechiffrement après révocation : révoquer un appareil supprime ses enveloppes et marque les fiches concernées needs_rotation, visible dans la liste sealed, /v1/sealed/rotation, la liste d'accès et la page mobile de rechiffrement. Le texte en clair déjà livré ne peut pas être rappelé : renouvelez d'abord le secret à la source, puis choisissez sur le téléphone « Rechiffrer pour tous les appareils », qui l'envoie uniquement aux appareils actuellement approuvés et efface le marqueur.
• Récupération de l'identité mobile : Center ne conserve jamais l'identité du téléphone. À sa création, un code de récupération unique est affiché : graine de 32 octets + somme de contrôle de 2 octets en Base32, par groupes de 4 caractères. Recopiez-le ; « Restaurer avec un code de récupération » rétablit la même identité.
• Rotation d'identité : « Migrer vers une nouvelle clé de téléphone » génère une nouvelle identité et soumet un enregistrement de rotation signé par l'ancienne et la nouvelle clé. Seuls les membres administrateurs peuvent le soumettre, et l'ancienne clé doit déjà être approuvée par un appareil. À la première utilisation, la CLI épingle la clé publique du téléphone approbateur dans hosted-device-trust.json et n'accepte que les signataires accessibles depuis cette racine par une chaîne de rotation vérifiée.
• Stockage matériel : la graine mobile est conservée avec les options intégrées les plus fortes de flutter_secure_storage : trousseau iOS/macOS passcode, local uniquement, sans synchronisation et nécessitant le code de l'appareil ; enveloppement Android Keystore avec biométrie ou identifiants de l'appareil requis, resetOnError: false. Limite : pour signer/chiffrer, la graine doit encore entrer dans la mémoire de l'application, car Secure Enclave/StrongBox ne prennent pas en charge X25519/Ed25519 ; seule la conservation au repos est protégée.
• Journal de transparence : Center maintient un journal d'appareils en ajout uniquement et chaîné par hachage, couvrant appairage, approbation, rotation d'identité et révocation, via GET /v1/devices/log. memories device hosted log --verify vérifie la chaîne, toutes les signatures et sa continuité avec la tête vérifiée précédemment dans hosted-device-log.json.

Biométrie et verrouillage de l'appareil sur mobile

Après déverrouillage du stockage en mode autonome, activez « Déverrouiller par biométrie/verrouillage de l'appareil » dans le menu Plus. L'activation exige d'abord une vérification système ; ce commutateur de sécurité protège aussi les opérations sensibles, notamment les approbations hébergées.

• Android : utilise BiometricPrompt du système, empreinte/visage, avec repli possible sur le PIN, schéma ou mot de passe de l'appareil. Le mot de passe de stockage nécessaire au déverrouillage rapide est protégé par une clé liée à Android Keystore, exigeant l'authentification utilisateur (setUserAuthenticationRequired) et automatiquement invalidée après ajout ou retrait d'une empreinte/d'un visage (setInvalidatedByBiometricEnrollment(true)).
• iOS : utilise Face ID/Touch ID avec repli sur le code de l'appareil ; l'élément du trousseau est disponible seulement si un code est défini sur l'appareil.
• Opérations protégées : déverrouillage du stockage, affichage ou copie d'identifiants en clair, utilisation de fiches protégées/génération OTP, approbation d'appareils appairés et de demandes hébergées, scellement (seal) et nouveau scellement (re-seal).
• Changement biométrique : si la clé devient invalide, l'application le signale explicitement sans supprimer le stockage ni les données. Après vérification avec les identifiants de l'appareil, saisissez une fois le mot de passe du stockage pour recréer la clé.
• Biométrie absente ou commutateur désactivé : sans biométrie/verrouillage de l'appareil disponible, ou lorsque le commutateur est désactivé, le parcours existant par mot de passe est conservé. Désactiver le commutateur supprime les informations enregistrées de déverrouillage rapide.

Créer du contenu sur mobile

Les nouvelles mémoires, identifiants et entrées du centre hébergé partagent le même éditeur : import depuis un fichier, avec son nom comme titre modifiable par défaut ; passage automatique à une édition multiligne à chasse fixe pour les configurations comme .env, également sélectionnable manuellement. Le nom peut rester vide au début : à l'enregistrement, il est déduit du nom du fichier, puis de la première ligne de texte non vide ; une saisie n'est demandée que s'il reste vide.

Les fiches de connaissance utilisent un formulaire plein écran avec bouton d'enregistrement fixe en bas ; « Modifier le contenu » ouvre l'éditeur partagé permettant import de fichiers, écriture manuscrite et scan. Les mémoires et fiches ne se ferment qu'après un enregistrement réussi ; en cas d'échec, le brouillon reste disponible pour réessayer et les soumissions multiples sont empêchées. Un import écrasant un contenu existant ou la sortie avec des modifications non enregistrées exige une confirmation. Les brouillons restent seulement en mémoire et ne sont pas restaurés après verrouillage en arrière-plan. L'édition des fiches autonomes et des fiches ordinaires hébergées conserve les étiquettes, sources, relations et champs personnalisés ; la création hébergée propose seulement les métadonnées acceptées par l'interface de création actuelle.

Identifiants à plusieurs champs

Un identifiant peut conserver plusieurs champs indépendants, tous facultatifs : nom d'utilisateur/compte, mot de passe, OTP (URI otpauth:// ou graine base32 et paramètres), clé API, URL, notes et champs personnalisés pouvant être marqués secrets. Les mots de passe, OTP, clés API et champs personnalisés secrets sont stockés uniquement dans le contenu chiffré ; les noms d'utilisateur, URL, notes et champs personnalisés non secrets sont directement consultables.

memories credential set VAULT [ASSET] --username 我 --url https://example.com --password --otp --field 团队=core --secret-field PIN
memories credential show VAULT ASSET
memories credential get VAULT ASSET --field username
memories credential get VAULT ASSET --field password --reveal
memories credential copy VAULT ASSET --field api_key
memories credential otp VAULT ASSET
memories credential migrate VAULT ASSET

Les valeurs secrètes sont saisies uniquement par entrée masquée, jamais comme arguments de commande. Les anciens identifiants à champ unique restent directement lisibles : ceux contenant otpauth:// ou dont le titre commence par OTP: sont associés à OTP ; ceux comportant une authentification HTTP ou des hôtes autorisés à une clé API ; les autres à un mot de passe. La première modification via credential set, ou credential migrate, les convertit au format structuré, en conservant les anciennes versions dans l'historique sans perte de données. Les fonctions existantes utilisant un secret unique, comme l'injection HTTP, les liaisons d'exécution et la copie sans --field, utilisent le « secret principal » : mot de passe en priorité, puis clé API, OTP, et premier champ personnalisé secret.

Identifiants à plusieurs champs : MCP, centre hébergé et synchronisation de bout en bout

• MCP credential_fields, avec permission de lecture, retourne uniquement les champs non secrets et les noms des champs secrets. credential_reveal, avec autorisation allow_all, exige intent: "reveal_plaintext" et un motif, retourne les valeurs champ par champ et les audite.
• Centre hébergé : pour les identifiants de bout en bout (e2e), seules les descriptions sont conservées au centre ; les champs secrets existent uniquement dans les enveloppes scellées des appareils.
• Appareils appairés : memories device sealed-get --vault V --card C --field password --reveal ; --otp génère un code de vérification.
• Mobile : la création d'un identifiant utilise un formulaire divisé en sections, connexion, code à usage unique, API, plus et champs personnalisés, tous facultatifs. Copier un champ secret ou consulter les codes de vérification en direct avec compte à rebours nécessite une vérification de déverrouillage système.