Tipos de tarjeta y campos personalizados

Las tarjetas de conocimiento de Memories admiten campos ordenados y tipados, además de su título, cuerpo del documento, etiquetas y enlaces existentes. Los tipos integrados son note, contact, link, snippet, checklist, event y credential. Un tipo proporciona campos iniciales, sin restringir los campos adicionales que puede contener una tarjeta.

Esquema

Content.card_type es una cadena opcional: un nombre integrado o el ID de una plantilla personalizada. Content.fields es un arreglo ordenado:

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

Los ID de campo permanecen estables al cambiar nombres y orden. Tipos de campo admitidos:

null significa vacío (u oculto para un campo sensible). Los tipos de selección requieren un arreglo options no vacío con elementos únicos; los demás tipos deben omitir options. Una tarjeta tiene como máximo 64 campos, con ID únicos, nombres de longitud limitada y valores limitados.

Cifrado y autorización

Cada revisión cifra el Content completo con el cifrado existente de la bóveda. Los valores sensibles de las tarjetas ordinarias se eliminan de fields y se almacenan en el field_body interno, un cuerpo estructurado base64url dentro de esa revisión cifrada, análogo a los cuerpos de credenciales. Base64url no es cifrado por sí mismo. Las operaciones normales de lectura, listado y consulta nunca devuelven field_body, y los valores de los campos sensibles aparecen como null. Los cuerpos de los documentos permanecen sin cambios y se pueden buscar; los valores sensibles no se incluyen en el cuerpo del documento ni en la caché de recuperación. Las diferencias muestran únicamente descriptores y campos no sensibles.

Una solicitud deliberada de card_fields con reveal: true requiere elevación verificada en CLI/móvil, o una capacidad MCP allow_all. La intención de entrega se audita y se confirma antes de devolver texto sin cifrar. Las capacidades MCP nunca heredan la elevación del terminal. La revelación de campos tipados en el móvil requiere además una comprobación biométrica/PIN del sistema satisfactoria, incluso cuando el desbloqueo rápido opcional está desactivado; las comprobaciones canceladas o no disponibles no obtienen valores sensibles. El editor del navegador de escritorio carece deliberadamente de endpoints para revelar secretos o contraseñas; utilice la aplicación nativa verificada o la CLI para los valores sensibles.

Plantillas reutilizables

Las plantillas son revisiones de tarjeta privadas, cifradas y firmadas que contienen type_template: {id, name, fields}. Utilizan el historial de revisiones, la autorización de la bóveda, la gestión de conflictos y la sincronización cifrada con dispositivos/nube existentes, en lugar de una base de datos auxiliar sin firmar. Se omiten de los listados y la recuperación de tarjetas ordinarias. Los tipos integrados no se pueden modificar ni eliminar. Se puede crear una plantilla personalizada a partir de una tarjeta existente; los valores sensibles predeterminados siempre se ocultan. Se rechaza la creación directa de una plantilla con un valor sensible predeterminado distinto de null.

Actualizar o eliminar una plantilla no reescribe las tarjetas existentes. Las tarjetas conservan sus propios campos y se pueden seguir editando después de eliminar su plantilla.

CLI

Inicie el daemon con el mismo directorio de inicio dedicado que utilizan los clientes:

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

Los valores sensibles se introducen mediante solicitudes de entrada oculta en el terminal, nunca mediante valores en la línea de comandos. Los números, las casillas y los valores de selección múltiple utilizan sintaxis JSON. Utilice los ID cortos devueltos por las operaciones de listado/consulta de la CLI, incluidos los ID de tipos personalizados. --fields acepta un arreglo JSON de campos.

Daemon, FFI y MCP

La ABI compartida JSON/C admite type_list, type_show, type_create, type_update, type_delete, card_create, card_fields y card_field. card_field.operation utiliza action: add|remove|reorder|rename|set con el campo, ID, índice de base cero, nombre nuevo o valor, respectivamente. El guardado de formularios nativos también utiliza replace para guardar atómicamente un arreglo ordenado de campos conservando los valores sensibles existentes ocultos. Estas operaciones añaden revisiones firmadas y conservan el tipo de activo original.

Las herramientas MCP utilizan los mismos nombres para las plantillas, card_fields para la inspección con valores ocultos y card_field_add|remove|reorder|rename|set para las modificaciones. card_field_reveal requiere un único ID de field, intent: "reveal_plaintext", un reason breve y el ámbito allow_all. MCP no puede solicitar la entrega de secretos de toda la tarjeta. Las escrituras normales requieren ámbito de escritura; la eliminación de tipos requiere ámbito de eliminación. Las modificaciones sensibles requieren una capacidad MCP allow_all verificada de forma independiente; esto no crea una sesión de elevación del terminal ni expone tarjetas ordinarias privadas.

Flutter utiliza la ABI JSON memories_call existente: no es necesario cambiar símbolos de la ABI. Su editor genérico incluye el selector de tipo, entradas por tipo de campo, cambio de nombre/eliminación de campos y reordenación mediante arrastre. El acceso alojado utiliza el mismo formulario y conserva la advertencia de que el servidor puede leer los datos.

Tarjetas alojadas y selladas por dispositivo

El RPC del SaaS alojado expone estas operaciones dentro de la bóveda y el ámbito del portador. Las tarjetas alojadas legibles por el servidor siguen utilizando cifrado de bóveda en reposo. Una tarjeta e2e no puede contener campos sensibles distintos de null ni un field_body interno; tanto la escritura directa como las modificaciones de campos rechazan valores sensibles sin cifrar. Los descriptores no sensibles se pueden editar sin enviar valores sensibles a Center.

El formulario móvil de sellado con dispositivo emparejado envía únicamente un sobre cifrado. Las tarjetas genéricas utilizan este texto sin cifrar para el sobre, construido en el cliente:

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

Center recibe el sobre, no ese texto sin cifrar. memories device sealed-get --vault V --card C --field key --reveal lee un campo en un dispositivo emparejado de confianza. Se siguen admitiendo los sobres heredados de secreto sin procesar y de credenciales estructuradas.

Compatibilidad

Los miembros de tipo y campo ausentes se deserializan con valores predeterminados. Las tarjetas existentes sin tipo se tratan como note sin reescribir sus cuerpos. Las credenciales heredadas se tratan como credential; los metadatos no sensibles se asignan a campos no sensibles y los valores secretos del cuerpo a campos sensibles durante la lectura. Las ediciones de campos de credenciales conservan el cuerpo de credencial estructurado existente para que los consumidores de copia, OTP e inyección sigan funcionando. Las credenciales binarias heredadas rechazan la migración genérica a campos de texto en lugar de descartar sus bytes. Las revisiones firmadas anteriores permanecen en el historial.

Actualice todos los dispositivos antes de intercambiar el nuevo esquema: los ejecutables antiguos que rechazan miembros JSON desconocidos no entienden las nuevas revisiones de tarjetas tipadas.