Types de fiches et champs personnalisés

Les fiches de connaissances Memories prennent en charge des champs ordonnés et typés, en plus du titre, du corps du document, des étiquettes et des liens existants. Les types intégrés sont note, contact, link, snippet, checklist, event et credential. Un type fournit des champs de départ, sans limiter les champs supplémentaires qu'une fiche peut contenir.

Schéma

Content.card_type est une chaîne facultative : le nom d'un type intégré ou l'ID d'un modèle personnalisé. Content.fields est un tableau ordonné :

{"id":"work-email","name":"Work email","kind":"email","value":"name@example.com"}

Les ID de champ restent stables après renommage et réorganisation. Types pris en charge :

null signifie vide (ou masqué pour un champ sensible). Les types de sélection exigent un tableau options non vide et sans doublons ; les autres types doivent omettre options. Une fiche contient au maximum 64 champs, avec des ID uniques, des noms et des valeurs de taille limitée.

Chiffrement et autorisation

Chaque révision chiffre l'intégralité de Content avec le chiffrement du coffre existant. Les valeurs sensibles des fiches ordinaires sont retirées de fields et stockées dans le field_body interne, un corps structuré en base64url à l'intérieur de cette révision chiffrée, comme les corps des identifiants. Base64url n'est pas en soi un chiffrement. field_body n'est jamais renvoyé par les opérations normales de lecture/liste/affichage, et les valeurs sensibles apparaissent comme null. Les corps des documents restent inchangés et consultables par recherche ; les valeurs sensibles ne sont placées ni dans le corps du document ni dans le cache de recherche. Les différences affichent uniquement les descripteurs et les champs non sensibles.

Une demande explicite card_fields avec reveal: true exige une élévation CLI/mobile vérifiée, ou une capacité MCP allow_all. L'intention de divulgation est auditée et enregistrée avant le retour du texte en clair. Les capacités MCP n'héritent jamais de l'élévation du terminal. La révélation des champs typés sur mobile exige en outre une vérification biométrique/PIN système réussie, même lorsque le déverrouillage rapide facultatif est désactivé ; une vérification annulée ou indisponible ne récupère aucune valeur sensible. L'éditeur du navigateur de bureau ne propose délibérément aucun point de terminaison de révélation de secret ou de mot de passe ; utilisez l'application native vérifiée ou la CLI pour les valeurs sensibles.

Modèles réutilisables

Les modèles sont des révisions de fiches privées, chiffrées et signées contenant type_template: {id, name, fields}. Ils utilisent l'historique des révisions, l'autorisation du coffre, la gestion des conflits et la synchronisation chiffrée entre appareils/cloud existants, plutôt qu'une base annexe non signée. Ils sont exclus des listes et de la recherche de fiches ordinaires. Les types intégrés ne peuvent être ni modifiés ni supprimés. Un modèle personnalisé peut être créé à partir d'une fiche existante ; les valeurs sensibles par défaut sont toujours masquées. La création directe d'un modèle avec une valeur sensible par défaut non nulle est rejetée.

La mise à jour ou la suppression d'un modèle ne réécrit pas les fiches existantes. Les fiches conservent leurs propres champs et restent modifiables après la suppression de leur modèle.

CLI

Démarrez le démon avec le même répertoire personnel dédié que les clients :

memories daemon
memories type list VAULT
memories type create VAULT Project --from-card CARD
memories type show VAULT TYPE
memories type update VAULT TYPE Project --fields template-fields.json
memories type delete VAULT TYPE
memories card create VAULT --title Ada --type contact
memories card put VAULT --title Notes --type note --input notes.md
memories card field add VAULT CARD Team --id team --kind text --value Core
memories card field add VAULT CARD Status --kind single_select --option Open --option Done
memories card field set VAULT CARD team Platform
memories card field rename VAULT CARD team "Working team"
memories card field mv VAULT CARD team 0
memories card field rm VAULT CARD team
memories card field list VAULT CARD
memories sudo
memories card field add VAULT CARD Key --kind sensitive
memories card field list VAULT CARD --reveal

Les valeurs sensibles utilisent des invites masquées du terminal, jamais des valeurs en ligne de commande. Les nombres, cases à cocher et valeurs à choix multiples utilisent la syntaxe JSON. Utilisez les ID courts renvoyés par les listes/affichages CLI, y compris les ID de types personnalisés. --fields accepte un tableau JSON de champs.

Démon, FFI et MCP

L'ABI JSON/C partagée prend en charge type_list, type_show, type_create, type_update, type_delete, card_create, card_fields et card_field. card_field.operation utilise action: add|remove|reorder|rename|set avec, respectivement, le champ, l'ID, l'index à partir de zéro, le nouveau nom ou la valeur. Les enregistrements des formulaires natifs utilisent aussi replace pour enregistrer atomiquement un tableau de champs ordonné tout en préservant les valeurs sensibles existantes masquées. Ces opérations ajoutent des révisions signées et conservent le type de ressource d'origine.

Les outils MCP utilisent les mêmes noms pour les modèles, card_fields pour l'inspection masquée et card_field_add|remove|reorder|rename|set pour les mutations. card_field_reveal exige un unique ID field, intent: "reveal_plaintext", un court reason et la portée allow_all. MCP ne peut pas demander la divulgation des secrets de toute une fiche. Les écritures normales exigent la portée d'écriture ; la suppression d'un type exige la portée de suppression. Les mutations sensibles exigent une capacité MCP allow_all vérifiée indépendamment ; cela ne crée pas de session d'élévation du terminal et n'expose pas les fiches ordinaires privées.

Flutter utilise l'ABI JSON memories_call existante : aucun changement de symbole ABI n'est nécessaire. Son éditeur générique comprend le sélecteur de type, des entrées adaptées à chaque type de champ, le renommage/la suppression des champs et leur réorganisation par glisser-déposer. Le mode hébergé utilise le même formulaire et conserve l'avertissement de lisibilité par le serveur.

Fiches hébergées et scellées pour un appareil

Le RPC SaaS hébergé expose ces opérations dans les limites du coffre et de la portée du jeton porteur. Les fiches hébergées lisibles par le serveur utilisent toujours le chiffrement du coffre au repos. Une fiche e2e ne peut contenir ni champs sensibles non nuls ni field_body interne ; l'écriture brute et les mutations de champs rejettent toutes deux les valeurs sensibles en clair. Les descripteurs non secrets peuvent être modifiés sans envoyer de valeurs sensibles au Center.

Le formulaire de scellement mobile pour appareil appairé n'envoie qu'une enveloppe chiffrée. Les fiches génériques utilisent ce texte en clair de l'enveloppe, construit côté client :

{"memories.card":1,"meta":{"card_type":"contact","fields":[
  {"id":"key","name":"Key","kind":"sensitive","value":null}
]},"body":{"text":"notes","sensitive":{"key":"value"}}}

Le Center reçoit l'enveloppe, pas ce texte en clair. memories device sealed-get --vault V --card C --field key --reveal lit un champ sur un appareil appairé de confiance. Les anciennes enveloppes de secrets bruts et d'identifiants structurés restent prises en charge.

Compatibilité

Les membres de type et de champ manquants sont désérialisés avec des valeurs par défaut. Les fiches existantes sans type sont traitées comme note sans réécriture de leur corps. Les anciens identifiants sont traités comme credential ; les métadonnées non secrètes correspondent à des champs ordinaires et les valeurs du corps secret à des champs sensibles lors de la lecture. Les modifications de champs d'identifiants conservent le corps structuré existant afin que la copie, l'OTP et les consommateurs d'injection continuent de fonctionner. Les anciens identifiants binaires rejettent la migration vers des champs textuels génériques plutôt que de perdre leurs octets. Les révisions signées précédentes restent dans l'historique.

Mettez à niveau tous les appareils avant d'échanger le nouveau schéma : les anciens exécutables qui rejettent les membres JSON inconnus ne comprennent pas les nouvelles révisions de fiches typées.