Guía de uso de Memories

Este documento explica cómo realizar las principales tareas implementadas con la CLI actual. Sustituye VAULT_ID, ASSET_ID y los demás identificadores en mayúsculas de los ejemplos por los ID cortos devueltos realmente por los comandos. Las contraseñas se leen sin eco desde una terminal interactiva. No hay argumentos ni variables de entorno para contraseñas. La aplicación no limita la longitud de las contraseñas locales ni de las copias de seguridad, y admite entradas vacías; los pasos que requieren confirmación solicitan introducirlas de nuevo.

Todos los comandos de datos requieren primero un daemon en ejecución que utilice el mismo directorio de datos. Opciones globales:

Los comandos devuelven JSON con versión. En caso de error, el código de salida es distinto de cero. Las palabras de confirmación USE y APPROVE permanecen en inglés, independientemente del idioma de la interfaz.

Linux admite la CLI, el daemon, el relay, la FFI y la página de estado descrita más abajo. Linux no dispone de bandeja nativa. La aplicación móvil no incluye una interfaz de recuperación mediante modelos, sincronización en segundo plano ni importación de códigos QR OTP con la cámara. El emparejamiento de dispositivos alojados permite escanear códigos de emparejamiento; consulta Secretos de extremo a extremo entre dispositivos. La validación de extremo a extremo con cuentas reales en la nube aún no se ha completado. La línea de comandos puede importar HOTP, otpauth:// y otpauth-migration://, y decodificar imágenes de códigos QR OTP con --image.

Encuentra el punto de entrada según la tarea

Si no conoces los parámetros, consulta primero la ayuda general y después la de cada subcomando; la ayuda no necesita daemon:

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

--lang zh solo cambia el idioma de la ayuda y los mensajes, sin modificar nombres de comandos ni sintaxis de parámetros. Los ejemplos sh de este documento utilizan un shell POSIX; la \ al final de una línea continúa el comando en la siguiente. En PowerShell/CMD, reúne las líneas en una sola.

Iniciar el daemon e inicializar la bóveda

Inicia el servicio en una terminal. Solo acepta conexiones del usuario actual del sistema operativo: utiliza canalizaciones con nombre en Windows y sockets Unix en Linux y macOS.

memories daemon

Abre otra terminal para inicializar el dispositivo, crear una bóveda, bloquearla y desbloquearla de nuevo:

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

--name es opcional; el nombre predeterminado del dispositivo es local-device. identity muestra la identidad pública del dispositivo. La inicialización, el desbloqueo y sudo requieren introducir la contraseña en una terminal interactiva. No dirijas --home a una carpeta ordinaria existente: el programa restringirá los permisos de ese directorio.

El almacenamiento local (store) es el directorio de datos seleccionado por --home; la inicialización crea la identidad local y la protección por contraseña. Una bóveda (vault) es una colección de datos delimitada por miembros y permisos; un almacenamiento puede contener varias bóvedas. Si utilizas un directorio personalizado, el servicio y todos los comandos de cliente deben llevar el mismo --home PATH. Una vez creado el almacenamiento, basta con unlock; no repitas init. Para incorporar un dispositivo nuevo a una identidad existente, completa primero el emparejamiento de dispositivos, sin crear antes una bóveda Personal o «Este dispositivo».

Tras completar los pasos anteriores, crea con un editor un archivo UTF-8 notes.md y escribe una nota de prueba que incluya «项目». Sustituye VAULT_ID en el ejemplo siguiente por el id devuelto por vault create o vault list para guardar y buscar tu primera memoria:

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

El id del resultado de guardado es el ASSET_ID que utilizarás después para leer. Usa memory para notas ordinarias; card cuando necesites etiquetas, categorías y relaciones; file para archivos originales como PDF, que no se convierten automáticamente en texto buscable; y credential para secretos, que no deben guardarse en notas ordinarias.

El unlock ordinario permite operar sobre datos ordinarios dentro de los permisos concedidos; no abre el acceso a contenido privado, archivos ni credenciales. sudo es una sesión de autorización local, no un permiso de administrador del sistema operativo. Utiliza la misma contraseña local, dura como máximo 15 minutos, caduca tras 5 minutos de inactividad y pertenece únicamente al proceso padre de esa terminal. Bloquear o reiniciar el servicio la elimina. El desbloqueo ordinario caduca tras 15 minutos de inactividad.

Consultar o crear configuración sin secretos:

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

config init no sobrescribe archivos existentes. config show no abre la bóveda cifrada. La configuración incluye storage_dir, relay_url, [desktop] y [rag]. No escribas contraseñas, claves privadas, tokens OAuth ni autorizaciones MCP en este archivo. Si cambias el directorio de almacenamiento o la configuración del modelo, reinicia también el daemon.

Escribir, leer y buscar memorias y tarjetas

Escribe una memoria ordinaria. Guarda el cuerpo en un archivo UTF-8 y pásalo con --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 aplica una expresión regular línea por línea al cuerpo descifrado de las memorias ordinarias de la bóveda seleccionada y devuelve DOCUMENT_ID:LINE; con -n / --line-number devuelve DOCUMENT_ID:LINE_NUMBER:LINE, y -i / --ignore-case ignora las mayúsculas. Los documentos privados, las versiones en conflicto, las tarjetas, los archivos y las credenciales no participan, igual que la búsqueda ordinaria excluye el contenido privado. Si no hay coincidencias, no se devuelve nada.

FROM_REVISION y TO_REVISION se obtienen del campo revision devuelto por history, no del campo id. La versión base es un argumento posicional, no --from; si omites --to, se compara con el head actual.

Cada creación o actualización añade una versión al DAG de revisiones firmadas de la bóveda (memorias ordinarias, tarjetas de conocimiento/brain, metadatos de tarjetas protegidas, archivos y credenciales). history de memory / card / file enumera versiones (revision, marca temporal, autor, si es head y resumen); read --revision lee cuerpos históricos; diff devuelve diferencias de texto unificadas, incluidos título y metadatos de tarjetas. Los diff de archivos omiten el cuerpo binario y solo comparan metadatos y longitud; el cuerpo secreto de las credenciales no puede devolverse mediante diff/read. Las revisiones se conservan a largo plazo con la bóveda, sin recorte automático.

Para leer una versión histórica, añade --revision REVISION. Para sustituir un registro, añade --id ASSET_ID. Si hay varias versiones sin fusionar, revisa el historial y utiliza --id ASSET_ID --resolve para enviar una versión nueva que apunte simultáneamente a esas versiones padre. Eliminar el registro visible actual:

memories memory delete VAULT_ID ASSET_ID

La eliminación no borra el historial firmado. --private marca el registro como privado. Los registros privados requieren sudo y se excluyen de la búsqueda ordinaria y de MCP.

Las tarjetas de conocimiento utilizan los mismos subcomandos de activos y pueden incluir etiquetas, fuentes, alias, notas, categorías y relaciones. card list (también memories list / memories ls en el nivel superior) permite omitir el ID de bóveda y examina todas las bóvedas accesibles; cada resultado incluye vault. --type knowledge|brain|persona|workflow|account|env|token|totp|hotp|otp filtra por summary.type (knowledge es una tarjeta de conocimiento ordinaria; brain, una tarjeta estructurada con resumen y enlaces tipados; otp representa totp+hotp); --otp equivale a --type otp. --category filtra por categoría y --group-by-category agrupa por categoría:

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

Al igual que memory delete, card delete solo retira la tarjeta de la vista actual; el historial firmado conserva las versiones anteriores. Eliminar tarjetas privadas o protegidas requiere sudo.

Las tarjetas brain guardan un abstract de texto plano buscable, sin convertirlo en secreto protegido, y enlaces entre bóvedas con la forma { vault?, card, role?, note? }. La sintaxis de --link es [VAULT/]CARD[=ROLE][|NOTE]; si contiene | o espacios, entrecomilla el valor completo para que el shell no lo interprete como una canalización. summary.type es brain e incluye link_count. Listas, grafos y lecturas resuelven los títulos y tipos de enlaces cuando los permisos lo permiten; los destinos inexistentes o inaccesibles se marcan como broken, sin eliminación en cascada. La búsqueda indexa títulos, resúmenes, roles/notas de enlaces y resúmenes de destinos públicos de la misma bóveda; nunca indexa secretos. Los enlaces brain dentro de la misma bóveda también aparecen en card graph.

El editor móvil permite escribir a mano y reconocer texto de fotos o imágenes, íntegramente en el dispositivo. Consulta Escritura a mano y reconocimiento de texto.

Tarjetas de flujo de trabajo (workflow) y plantillas de listas

El summary.type de las tarjetas de flujo de trabajo es workflow. Los pasos ordenados se guardan en las revisiones de la tarjeta; cada paso tiene el estado pending, active, done o skipped, y la tarjeta también tiene un estado global. --step acepta TITLE o ID:TITLE; puedes añadir =CARD al final para vincular una tarjeta. Repite la opción para cada paso:

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 avanza el paso indicado; si no se indica ninguno, avanza el paso active actual y, si tampoco existe, el primer paso pending.

Las plantillas de listas también son tarjetas de tipo workflow, con template igual a true en sus datos. Al crear una plantilla, --template no lleva valor y se requieren --assignee, --summary y --goal. --assignee puede ser un ID de tarjeta persona, un ID de persona o cualquier nombre; --assignee-name es el nombre visible y, al apuntar a una tarjeta persona, utiliza por defecto su nombre visible. --template TEMPLATE_ID copia los campos de lista y enlaces de flujo de la plantilla en una tarea:

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 vincula otra tarjeta workflow de la misma bóveda; --archive archiva una memoria o tarjeta y puede repetirse. --clear-workflow y --clear-archives de workflow-update eliminan respectivamente esos dos tipos de enlaces. Si la tarea no tiene pasos propios, --advance, --step, --step-status y --status actúan sobre el flujo asociado. El informe de aceptación --acceptance puede estar vacío antes de completar la tarea.

Tarjetas de personalidad (persona)

Las tarjetas persona sincronizan personalidad y comportamiento entre productos como Grok Bot / Muse. La tarjeta persona de la bóveda y sus archivos vinculados son la fuente autoritativa.

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

• Núcleo (core): cómo hablar y actuar; se revisa mediante persona put / persona_card.
• Archivos (archives): contratos, diarios, atuendos, perspectivas y otras tarjetas de conocimiento independientes enlazadas por archives de la persona; no las copies al núcleo.
• Eventos de comportamiento: append-event añade eventos al archivo events, de forma acumulativa.

El estado del mundo, los objetos, la automatización y las conversaciones entre personas también se mantienen mediante subcomandos persona. Si omites VAULT_ID PERSONA_ID, se utiliza persona de los valores predeterminados del cliente:

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

• Estado del mundo: world-set actualiza ubicación, postura, atuendo, cantidades de objetos, clima, dados, ruleta, agenda, etc.; world-rollover inicia explícitamente un nuevo día del registro al cambiar de día y solo borra campos diarios como meals, orders_done, el resumen breve look y counters_today, conservando los contadores acumulados.
• Objetos (things): thing put/get/list/delete/image administra objetos arbitrarios; thing attr get/set/delete lee y escribe atributos individuales mediante rutas con puntos o JSON Pointer; attrs es JSON libre.
• Automatización: automation put/list/run/trigger/delete administra hooks guardados en el estado del mundo, con la zona horaria timezone de la persona. webhook_out saliente solo puede enviarse a URL que coincidan exactamente con la lista permitida; la lista vacía predeterminada bloquea todos los POST salientes. Se administra mediante automation webhook-allow --add URL / --remove URL. Los tokens webhook no se devuelven en las respuestas; solo se muestra webhook_token_set.
• Conversaciones: mensajes entre dos tarjetas persona de la misma bóveda. Al enviarlos se activan los hooks de automatización chat_message de ambas, con una carga que no incluye el cuerpo del mensaje. chat list muestra conversaciones; leer history no marca como leído: se necesita chat mark-read.

Consulta la Guía de tarjetas persona, en inglés.

Al crear tarjetas ordinarias también puedes repetir --link TARGET_ID=RELATION. Estas relaciones deben apuntar a tarjetas de la misma bóveda. El grafo omite nodos eliminados, en conflicto o no autorizados y las aristas que los conectan. --include-private requiere sudo.

Archivos privados:

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 admite --title y --id. file export admite --revision. file history enumera las revisiones firmadas del archivo; file diff solo compara título, metadatos y longitud, sin devolver el cuerpo binario.

Usa file exec para entregar una configuración almacenada a un programa local; {file} en los argumentos se sustituye por la ruta absoluta del archivo temporal:

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

Los permisos son los mismos que para file export: se requiere desbloqueo, acceso a la bóveda y memories sudo en la misma terminal. Añade --revision REVISION antes de -- para utilizar una versión histórica. Incluso si lees desde un daemon remoto o alojado, el programa se ejecuta en el equipo local de la CLI como usuario actual. El comando lo inicia directamente, sin pasar por un shell; conserva el directorio de trabajo, las variables de entorno, la entrada y salida estándar y el código de salida, sin límite de ejecución de cinco minutos ni respuesta JSON de éxito.

Solo el usuario actual puede acceder a los archivos y directorios temporales (permisos Unix 0700/0600 y ACL de usuario en Windows). El programa debe ejecutarse en primer plano: el archivo temporal se conserva hasta que finaliza el proceso hijo y también se limpia si falla el inicio. En Windows, Ctrl+C/Ctrl+Break y, en Unix, SIGINT/SIGTERM/SIGHUP activan la limpieza al salir, con una espera máxima de diez segundos y posterior terminación del hijo directo. Las señales Unix se reenvían al hijo; los eventos de consola de Windows llegan a los procesos que comparten esa consola.

Durante la ejecución, la configuración está en texto plano y el programa y sus complementos pueden leerla y mostrarla; la salida no se redacta. Bloquear la bóveda o revocar la autorización no retira copias ya entregadas ni detiene el programa. Forzar el cierre de Memories, cortar la alimentación o cerrar la consola de Windows puede dejar archivos temporales; eliminarlos no equivale a borrado seguro, y no se administran descendientes en segundo plano separados del proceso padre. Cada ejecución utiliza una única instantánea fija llamada config, sin actualizaciones automáticas, reload, expansión de plantillas ni importación de archivos relacionados. Las rutas relativas se interpretan según las reglas del programa de destino; se recomiendan rutas absolutas para configuración asociada y certificados, indicando explícitamente el formato cuando sea necesario.

Utiliza los ID cortos devueltos por listas y búsquedas sin modificarlos. Los UUID largos, hashes completos de revisión e ID con prefijos se rechazan. Si la entrada es ambigua, el comando falla y debes volver a listar o buscar.

Registrar Python solo en este equipo:

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

Ejecuta el intérprete seleccionado en modo aislado, registra su versión y el directorio del ejecutable, sin recopilar variables de entorno. El resultado se guarda en la bóveda «Este dispositivo», marcada con local_only.

Recuperación y respuestas con citas

Configura primero el daemon con la misma configuración que contenga [rag]. Importar texto UTF-8 o Markdown crea una tarjeta de conocimiento ordinaria y devuelve el número estimado de fragmentos:

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

Opciones de rag search y rag ask:

Instalar los pesos incorporados de EmbeddingGemma y crear un índice vectorial en memoria:

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 no inicializa la bóveda cifrada. Los pesos se instalan por defecto en models/embeddinggemma dentro del directorio de datos seleccionado. La inferencia local se ejecuta dentro del proceso Memories y no necesita Ollama. Las búsquedas vectoriales e híbridas también calculan embeddings bajo demanda cuando el índice aún no está completo.

rag ask requiere la dirección de generación en la configuración. Para recuperación exclusivamente léxica, utiliza --mode bm25; toda consulta de preguntas y respuestas sigue necesitando la dirección de generación. Si no hay evidencia, no se llama al servicio de generación y insufficient_evidence es true. [S1] en la respuesta es únicamente una etiqueta de cita de ese resultado. Para abrir el original, utiliza el id del activo del resultado, sin confundir el hash del fragmento con el ID del activo:

memories memory read VAULT_ID ASSET_ID

No se extrae texto automáticamente de PDF, DOCX ni archivos binarios. Conviértelos primero a texto UTF-8 y luego impórtalos. No importes como tarjetas ordinarias textos que deban permanecer secretos. Reinicia el daemon si cambias la configuración del modelo.

Los embeddings remotos, la generación y la reclasificación se configuran en [rag.embedding], [rag.generation] y [rag.rerank]. Para claves API, escribe únicamente el nombre de la variable de entorno, por ejemplo api_key_env = "GEMINI_API_KEY", y guarda el valor en el entorno del daemon. Si omites [rag.embedding], los embeddings siguen utilizando el modelo local. Gemini Embedding es una API en línea, diferente de EmbeddingGemma sin conexión.

Capturar y utilizar credenciales y tarjetas protegidas

Ejecuta primero memories sudo en la misma terminal.

Añade credenciales mediante entrada oculta o impórtalas desde archivos existentes. La importación no elimina el archivo original:

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

memories catch equivale a memories credential catch. Si no indicas una fuente, solicita entrada oculta:

memories catch VAULT_ID "数据库密码"

Para leer desde una canalización, añade --stdin. --regex extrae una única coincidencia; si hay un grupo de captura, guarda ese grupo, y si no lo hay, guarda la coincidencia completa. --json-pointer selecciona una cadena JSON. No pueden utilizarse simultáneamente:

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 inicia directamente el programa y captura su salida estándar, cierra la entrada estándar del hijo y descarta su salida de error. Después de -- van los argumentos del programa; no pongas secretos reales en argumentos, expresiones regulares ni títulos. --timeout admite de 1 a 300 segundos, con 30 segundos por defecto. La entrada estándar por canalización espera hasta EOF, sin tiempo límite. El límite de entrada es 1 MiB. El resultado satisfactorio solo contiene el ID de credencial. Usa --id CREDENTIAL_ID para sustituir una credencial existente.

Generar claves dentro de la bóveda. Las claves privadas no se muestran:

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 puede ser ssh, tls-ca o tls. --algorithm puede ser ed25519, rsa o ecdsa. credential public solo devuelve la clave pública SSH o el certificado TLS.

Entrega una credencial a un programa situado en una ruta absoluta. Se inyecta por entrada estándar de forma predeterminada; --env autoriza explícitamente una variable de entorno. Debes confirmar interactivamente el SHA-256 del programa o aprobarlo previamente con --approve-digest. Se suprimen ambas salidas del hijo:

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

Los enlaces de ejecución fijan una credencial a la huella de un programa para que un agente de programación pueda utilizarla sin el sudo de tu terminal. credential bind gh requiere sudo y confirmación con USE: localiza gh en PATH, registra su SHA-256 y guarda el enlace únicamente en el estado cifrado local, sin sincronizarlo; restaurar una copia de seguridad también lo elimina. El enlace caduca tras --hours horas (8 por defecto, como máximo 720) y solo puede utilizarse mientras la bóveda esté desbloqueada. Después, run --binding gh -- 参数 inicia el programa en el directorio actual, coloca la credencial en la variable de entorno indicada, devuelve la salida sin cambios salvo que sustituye todas las apariciones de la credencial por [REDACTED] (con --suppress-output descarta la salida) y termina con el código de salida del programa:

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 词 rechaza comandos cuyos argumentos que no sean opciones contengan esas palabras en orden; --ask 词 hace que el hook solicite confirmación antes de ejecutar. Para gh, por defecto se rechazan auth, alias, extension y sus alias extensions, ext, y se pide confirmación para pr merge, repo delete y release delete; --no-default-rules desactiva estas reglas. Las reglas solo comparan las palabras introducidas, sin expandir alias definidos previamente con gh alias set. Hasta que caduque el enlace, cualquier programa que se ejecute con tu identidad puede ejecutar el programa vinculado con la credencial, aunque no puede leer la credencial mediante memories. El propio programa, sus extensiones e hijos sí pueden leerla; vincula únicamente programas de confianza. Los enlaces sin --credential ni --env solo aplican reglas.

hook install --commands gh muestra las entradas, solicita APPROVE y escribe un hook PreToolUse en la configuración de usuario de Claude Code. Cuando Claude Code ejecuta gh ... en Bash o PowerShell, el hook sustituye ese comando por memories run --binding gh -- y conserva el resto de la línea. Se rechaza gh ejecutado dentro de envoltorios como $( ), comillas invertidas, sh -c o xargs, con explicación del motivo; el cuerpo de heredoc y las sustituciones de comandos usadas como argumentos (por ejemplo --body "$(cat <<'EOF' ... EOF)") no se ven afectados. La entrada de canalizaciones o redirecciones se reenvía mediante --stdin, hasta 16 MiB. El programa se ejecuta en el entorno del daemon, por lo que se rechazan prefijos como NAME=value gh ...; utiliza los argumentos del propio programa. Los argumentos expandidos solo durante la ejecución ($var, comodines) no pueden comprobarse contra las reglas y el hook pide confirmación previa. Solo deja pasar directamente cuando toda la línea es una llamada al programa vinculado; si también ejecuta otros programas o escribe archivos, sigue la confirmación habitual de Claude Code. Si procesos en segundo plano del programa vinculado mantienen abiertas las canalizaciones de salida, existe un límite de hilos lectores; al superarlo se rechazan nuevas ejecuciones vinculadas. Las reglas deny / ask de Claude Code siguen vigentes, aunque pueden ver el comando reescrito: incluye los subcomandos sensibles en las reglas del enlace. El programa vinculado se ejecuta fuera del bloqueo del servicio, por lo que un gh run watch largo no bloquea a otros clientes, pero conserva el límite de 5 minutos.

Limita los hosts permitidos para una credencial y haz que el daemon envíe solicitudes HTTPS que solo devuelvan el código de estado:

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 solo utiliza el puerto HTTPS 443, no sigue redirecciones y no hereda proxies.

Las tarjetas protegidas también leen secretos mediante entrada oculta, sin introducirlos como argumentos:

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

SMTP de las cuentas utiliza por defecto SSL en el puerto 465; puede ajustarse con --port y --no-ssl. Solo registra configuración, no envía correo. --cookie guarda la tarjeta token como una cabecera Cookie. --method de card request es GET por defecto y solo acepta GET o POST. OTP admite --algorithm sha1|sha256|sha512, --digits y --period. --hotp cambia a HOTP y --counter indica el contador inicial, 0 si se omite; TOTP ignora el contador. otp-import acepta una URI como argumento; si no hay URI ni --image, lee una línea de la entrada estándar. Para una sola cuenta se utiliza otpauth://. Se identifica automáticamente totp o hotp de la URI; sin tipo explícito, la presencia de counter indica HOTP y, en caso contrario, TOTP. La migración de Google Authenticator usa otpauth-migration://offline?data=... y puede crear varias tarjetas a la vez. --image PATH decodifica el primer código QR otpauth:// u otpauth-migration:// de una imagen y no puede combinarse con una URI. --title es opcional: para una tarjeta indica el título, y para varias, el prefijo de los títulos; si se omite, el título es «Emisor / Cuenta». --id solo sustituye una tarjeta y no admite importaciones de migración con múltiples cuentas. otp-code devuelve códigos temporales, sin devolver la semilla; HOTP incluye el siguiente contador en el resultado. El secret anterior es un vector de prueba público de RFC: no lo sustituyas por una semilla real.

Para sustituir una tarjeta protegida, añade --id CARD_ID. Se conservan el ID de credencial y los enlaces de la tarjeta. --alias / --notes / --category mantienen sus valores si no se pasan; una cadena vacía los borra. El card put ordinario no puede sustituir referencias protegidas. Los títulos OTP pueden conservar issuer / account; utiliza alias y notas para guardar por separado el nombre visible.

Protege un secreto que aparezca exactamente una vez en el cuerpo de un documento. La etiqueta debe tener de 1 a 64 letras ASCII, dígitos, guiones bajos o guiones, y no debe haberse utilizado en ese documento:

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 solicita el secreto. Para copiar referencias de documentos es obligatorio --label. El resultado de copiar solo contiene "copied": true. Windows utiliza el portapapeles del sistema, macOS pbcopy, y Linux necesita wl-copy de Wayland o xclip de X11. Las tarjetas protegidas de cuenta, token, entorno y OTP también pueden copiarse directamente; en OTP se copia la semilla, no el código de un solo uso.

En móvil existen «Tarjetas protegidas», «Importar .env» e «Importar datos de acceso (CSV)»; también puedes pegar una URI otpauth:// para importar TOTP o HOTP. «Sustituir claves en los datos» y «Copiar clave» del menú del documento corresponden a las operaciones anteriores. «Generar OTP» produce un código de un solo uso. El móvil no importa códigos QR OTP mediante la cámara; utiliza la CLI anterior para imágenes OTP y URI de migración. El escaneo para emparejar dispositivos alojados sigue otro proceso: consulta Secretos de extremo a extremo entre dispositivos.

Importar y exportar datos de acceso a sitios web

Los accesos a sitios se guardan en tarjetas protegidas login, con dirección y usuario públicos y contraseña como credencial independiente, y suelen importarse y exportarse por lotes. Ambas operaciones requieren memories sudo y un rol con escritura:

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

Si el host del sitio y el usuario coinciden con una tarjeta existente y la contraseña es igual, se omite; si la contraseña difiere, se registra un conflicto y se crea otra tarjeta. Solo --update sobrescribe. Las filas CSV inválidas se omiten y se notifican por número de línea; cada importación admite como máximo 2000 entradas. La columna note del navegador solo se importa con --with-notes, porque las notas entran en el índice ordinario de texto completo. La lectura directa de Firefox admite el formato moderno de claves, desde Firefox 58; para perfiles más antiguos, exporta CSV desde about:logins. Leer contraseñas guardadas del navegador no modifica su almacenamiento.

La exportación cifrada utiliza una contraseña independiente y puede importarse en cualquier bóveda. La exportación CSV es texto plano para devolver accesos a un navegador u otro gestor de contraseñas: solo se permite en la CLI local, avisa previamente y escribe en un archivo nuevo, legible solo por su propietario; además protege contra inyección de fórmulas las celdas que empiecen por = + - @. Elimínalo después de utilizarlo. Las bóvedas exclusivas del dispositivo no pueden exportarse.

Sesiones remotas y proxies de bucle local

Autoriza primero el host de destino con credential allow-host. Para SSH, utiliza también la huella de clave del host obtenida por la sonda y compruébala mediante 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 realiza propuesta, aprobación interactiva y ejecución en una sola operación. Si un script necesita separarlas, remote propose encola la propuesta y devuelve un ticket, remote approve la aprueba (requiere sudo y el ticket solo puede usarse una vez), y el mismo invocador con elevación ejecuta remote exec.

Las bases de datos activan TLS y verifican el nombre del host por defecto. --tls-ca CA_ID añade una CA PEM almacenada en la bóveda. --no-tls desactiva TLS explícitamente. --database es el nombre de base de datos MySQL/PostgreSQL o el índice de base lógica 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

Los protocolos de remote open son ssh, ftp, tcp, mysql, redis y postgres. FTP utiliza operaciones de archivo; SSH y las sesiones de base de datos utilizan exec o query. Cada instrucción se propone antes de aprobarse. remote run reúne propuesta, aprobación interactiva y ejecución. La palabra de aprobación es APPROVE. MCP no puede abrir ni aprobar sesiones remotas.

El proxy de bucle local escucha en 127.0.0.1. El command devuelto puede ejecutarse en una terminal del equipo donde corre el daemon y no contiene contraseñas ni claves privadas almacenadas:

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

Los protocolos del proxy son únicamente ssh, mysql, redis y postgres. --listen-port es opcional y 0 permite que el sistema elija el puerto. También son opcionales --certificate, --tls-ca, --tls y --no-tls. Cualquier proceso que pueda conectarse al puerto local puede utilizar la cuenta remota ya autorizada. El bloqueo, el bloqueo por inactividad de la bóveda, proxy stop y la salida del daemon cierran el listener y las conexiones existentes. Los proxies duran como máximo 30 minutos; se admiten cuatro proxies, cada uno con hasta 16 conexiones. MCP no puede iniciar, enumerar ni detener proxies.

Ejecutar trabajos criptográficos

Las herramientas de correo y firma se instalan por separado. La identidad y su contraseña se importan como dos credenciales. --credential, --password_id y --key-password son ID de credenciales, no los secretos. --password y --password-id son alias de --password_id.

Añade primero --dry-run. Lee entrada y herramientas, muestra el plan y el resumen approval, sin necesitar daemon ni escribir archivos de salida. Tras confirmar, ejecuta sudo en la misma terminal y repite el comando sin --dry-run. Para ejecución no interactiva, añade --approve-digest DIGEST. La salida debe ser una ruta nueva dentro de un directorio existente.

S/MIME utiliza OpenSSL. Añade --pkcs12 para identidades PKCS#12. El cifrado solo utiliza la clave pública del destinatario, por lo que no se pasa credencial de identidad:

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 requiere gpg y gpgconf conjuntamente. --identity es la huella completa. Para GnuPG MSYS de Git for Windows, añade --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 firma Android no genera paquetes de instalación ni contacta con tiendas de aplicaciones. La ruta de apksigner es lib/apksigner.jar del 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 la contraseña de la clave difiere de la del almacén, utiliza --key-password KEY_PASSWORD_ID.

La firma iOS solo está disponible en macOS. La entrada es una .app que ya contiene un embedded.mobileprovision correspondiente:

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

Estos comandos no envían correo ni publican aplicaciones. MCP y el móvil no pueden ejecutarlos.

Emparejar dispositivos, sincronizar y crear copias de seguridad

El emparejamiento incorpora un dispositivo nuevo de una misma persona a su identidad existente; una invitación de miembro concede a otra persona un rol en una bóveda. Ambos usan archivos de solicitud y aprobación, pero no son intercambiables.

El dispositivo nuevo debe ejecutar primero init con su propia contraseña y no tener bóvedas antes de incorporarse. Después:

memories sudo
memories device invite request.json

Entrega el archivo de solicitud al dispositivo existente. Comprueba la huella completa de invitación mostrada en el dispositivo solicitante antes de aprobar. El comando de aprobación devuelve la clave pública del dispositivo aprobador; verifícala por un canal fiable antes de aceptar en el dispositivo nuevo:

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

De vuelta en el dispositivo nuevo, ejecuta otra vez sudo en la misma terminal que realizará la aceptación y luego acepta y comprueba la lista de dispositivos:

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

La solicitud caduca tras 10 minutos y solo puede utilizarse una vez.

Aprobar la pertenencia de otra persona a una bóveda:

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 al aprobar invitaciones y el argumento de rol de member role deben utilizar admin, editor o reader, según los permisos del operador: el propietario administra administradores; los administradores solo gestionan lectores y editores ordinarios; los editores pueden escribir y los lectores leer y utilizar. Aunque la CLI acepta owner, la política exige exactamente un propietario, por lo que no puede añadirse otro por invitación ni cambio ordinario de rol. Para transferir la propiedad, el propietario actual ejecuta memories member transfer VAULT_ID USER_PUBLIC_KEY; el destino debe ser un miembro existente y el antiguo propietario pasa a administrador. La revocación de dispositivos debe ejecutarse en cada bóveda afectada. Eliminar un miembro no borra las copias que ya posee.

Intercambio de archivos sin relay:

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

Para transferencia en línea, ejecuta primero memories-relay detrás de un proxy inverso TLS y genera una sala con sync room. El destinatario espera primero y después el remitente envía:

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

Los relays remotos solo aceptan wss://; ws:// se permite únicamente para direcciones locales de desarrollo. La URL no puede contener usuario ni contraseña. relay_url de la configuración puede indicar la dirección predeterminada y --relay la sobrescribe. --slot utiliza a por defecto al enviar y b al recibir. Un envío satisfactorio solo significa que el paquete llegó al relay, no que el destinatario lo importó. El relay no encola para dispositivos desconectados. Tanto sync export/import como sync send/receive mediante relay son transferencias explícitas de la bóveda completa, no sincronización de objetos en la nube ni RPC remoto.

Consultar la cuarentena, volver a firmar revisiones de épocas anteriores en la actual y conservar la rama de política local cuando ambas identidades de propietario son válidas:

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

Las cuentas en la nube utilizan aplicaciones OAuth registradas por ti. Antes de iniciar sesión, desbloquea la bóveda y ejecuta sudo en la misma terminal:

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 admite --no-browser y --port; 0 selecciona automáticamente el puerto local de retorno. El estado no muestra tokens. Cerrar sesión solo elimina la autorización local. cloud sync renueva tokens y carga y descarga texto cifrado inmutable mediante la carpeta de aplicación de OneDrive o Google Drive conectada. El móvil ofrece conexión a la nube y sincronización en primer plano. La validación de extremo a extremo con cuentas reales de OneDrive y Google Drive aún no se ha completado. La sincronización móvil en segundo plano no está habilitada. No coloques el directorio de la base de datos en una carpeta sincronizada por el cliente de disco en la nube.

Auditoría y copia de seguridad sin conexión:

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

La restauración debe utilizar un directorio de datos nuevo, con un daemon iniciado en ese directorio:

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 restauración produce una bóveda independiente con los activos actuales y heads en conflicto. Las versiones originales, tombstones y la auditoría firmada quedan en un archivo de solo lectura. Los valores históricos de credenciales no pueden mostrarse mediante las interfaces ordinarias ni de archivo. Las bóvedas específicas del dispositivo y los tokens de nube no se incluyen en la copia.

Abrir la interfaz de estado de escritorio

En el paquete Windows, haz doble clic en memories-tray.exe, situado junto a memories.exe. En macOS, abre Memories.app del paquete. Desde una 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 abre la bandeja nativa o la barra de menús con página de estado. webui abre únicamente el panel del navegador y permanece en primer plano. --port 0 selecciona un puerto libre de bucle local. --no-open evita abrir automáticamente el navegador. --open lo abre incluso si la configuración desactiva la apertura automática. --config y --lang también se aplican a ambos comandos y a memories-tray.

La bandeja muestra estados desconectado, pendiente de inicialización, bloqueado o desbloqueado y permite iniciar el daemon. No inicializa, desbloquea ni eleva permisos. La página de estado se actualiza aproximadamente cada dos segundos y muestra cantidad de bóvedas, proxies y sesiones remotas, tipos de proveedores de nube configurados y contadores de cargas, descargas y sincronizaciones pendientes. No muestra cuerpos, nombres de bóveda, credenciales, cuentas, rutas ni tokens. Salir de la bandeja o interrumpir webui en primer plano solo detiene esa página, sin detener el daemon existente.

En Linux utiliza memories webui. No hay bandeja nativa ni lanzador de bandeja en los paquetes Linux.

Conceder MCP e instalar skills de IA

Esta sección presenta primero MCP ordinario: concede capacidades al cliente de IA para una bóveda, duración y alcance de operaciones, sin heredar sudo de la terminal. La autorización se escribe en un archivo, sin mostrarse; el archivo es una credencial bearer y debe protegerse. El valor predeterminado es solo lectura; --scope read_write permite leer y escribir datos ordinarios, --scope read_write_delete también permite eliminarlos y --write es una abreviatura compatible de read_write. La duración se indica con --minutes; el ejemplo utiliza 15 minutos:

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

Configura el comando stdio MCP del cliente de IA como memories mcp serve --grant-file ..., usando el mismo directorio de datos que el daemon. Las herramientas son 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 y workflow_list, además de las herramientas persona de la Guía de tarjetas persona, en inglés. workflow_card crea flujos por pasos, plantillas de listas o tareas copiadas de plantillas; workflow_update modifica campos de listas o avanza pasos. Ambas requieren escritura; workflow_read y workflow_list solo requieren lectura. Cada llamada incluye el ID de bóveda autorizado. memory_retrieve utiliza BM25 local por defecto; vector e hybrid utilizan el proveedor de embeddings configurado en el daemon. memory_ask responde cuando hay dirección de generación configurada y rechaza citas ajenas a la evidencia recuperada.

MCP ordinario excluye memorias privadas, archivos, credenciales, ejecución de procesos, sesiones remotas, proxies, trabajos criptográficos, gestión de miembros y estado de escritorio. Ni siquiera --scope allow_all supera este límite. Emitir, enumerar y revocar autorizaciones y solicitar permisos son herramientas MCP distintas, que tampoco heredan sudo. El bloqueo inutiliza temporalmente las autorizaciones; las no caducadas vuelven a funcionar al desbloquear. La versión del protocolo es 2024-11-05. Las tarjetas con referencias secretas no pueden actualizarse con el card_write actual porque no conserva el mapa de referencias; edítalas con la CLI o el móvil.

Si necesitas lectura desatendida, consulta por separado CLI/MCP desatendidos. Esta vía exige seleccionar explícitamente un backend de custodia de claves, introducir ENABLE, autorizar con contraseña y crear un archivo de cliente limitado a la bóveda. Utiliza mcp serve-unattended --client-file PATH, distinto de mcp serve ordinario. Es local y de solo lectura, pero incluye datos privados, archivos originales, historial y texto plano de credenciales solicitado explícitamente, sin heredar sudo. El cliente de IA y sus registros pueden conservar secretos; Base64 no es cifrado. El bloqueo manual impide persistentemente este acceso hasta un unattended resume autorizado con contraseña. No está disponible para transportes remotos, móviles ni almacenamientos administrados por Center.

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

Los backends disponibles son windows-dpapi, macos-keychain, linux-secret-service y owner-file, que requiere elección explícita y ofrece menor protección. El directorio del archivo de cliente debe existir y ser accesible solo para el propietario; mint no sobrescribe archivos existentes. read y credential-bytes devuelven bytes en fragmentos base64url: comienza con --offset 0, utiliza el next de la respuesta anterior como nuevo --offset y fija con --revision la revisión devuelta inicialmente, hasta que next sea null; luego concatena los bytes decodificados en orden. list / history devuelven como máximo 100 entradas por página. status, resume, revoke y disable requieren una terminal desbloqueada y con sudo.

Instalar el skill incluido con el programa. La instalación no abre la bóveda ni configura MCP:

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

all incluye Codex, OpenCode y Claude Code. claude-code es un alias de claude. --project instala en un directorio de proyecto existente. Tras actualizar la CLI, usa --force para sustituir contenido instalado anteriormente que sea diferente:

memories inject all --force

--force solo sustituye SKILL.md. El contenido idéntico se conserva. Se rechazan enlaces que apunten al archivo o directorio del skill.

Genera para un proyecto un AGENTS.md que explique cómo operar Memories o un directorio de skill de estilo Cursor/Codex; opcionalmente incorpora el resumen del núcleo de una tarjeta persona. agents es 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, predeterminado, escribe un archivo Markdown; --layout skill escribe SKILL.md en el directorio de salida, o directamente el archivo si la ruta ya termina en .md. Si omites --persona, se utiliza persona de los valores predeterminados del cliente. La generación con persona lee la tarjeta mediante el daemon y requiere desbloqueo previo; sin persona se genera sin conexión y sin daemon. --force sustituye archivos existentes con contenido distinto; --dry-run solo muestra una vista previa sin escribir.

Valores predeterminados del cliente

Los valores predeterminados de CLI sin secretos se guardan en defaults.json dentro del directorio de datos (--home / MEMORIES_HOME), fuera del texto cifrado de la bóveda:

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

Los argumentos explícitos siempre tienen prioridad. Los subcomandos persona que aceptan bóveda y activo (world-get, thing, append-event, etc.) utilizan los valores predeterminados para argumentos posicionales omitidos; persona import sigue requiriendo indicar el ID de bóveda antes de la ruta del skill.

Centro de autorización (Center)

Center es un plano externo de control de autorizaciones que distribuye tickets de registro y de capacidades a los clientes. Si la configuración contiene cualquier [[centers]], ese cliente queda administrado por Center: se prohíben el arranque local mediante init / restore y la autorización MCP local, sustituidos por tickets emitidos por Center. El desbloqueo sigue siendo local, con la contraseña del dispositivo; Center no obtiene las claves de la bóveda ni secretos en texto plano. Los tokens del listener, las claves de firma de Center y los tokens administrativos no se escriben en 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"

Consulta los alcances (read, write, read_write, read_write_delete, allow_all y sus alias), el formato de configuración y el modelo de amenazas en Centro de autorización, en inglés.

Bóvedas alojadas (SaaS)

memories-center --data DIR, o la variable de entorno MEMORIES_CENTER_DATA, permite a Center ejecutar una bóveda alojada completa: el servidor guarda Store cifrado con una contraseña del operador y reutiliza las mismas interfaces de servicio del daemon. La única entrada con mode = "saas" en la configuración pone al daemon local en modo SaaS; ese Center controla las operaciones de contenido y el token procede de MEMORIES_CENTER_TOKEN. Los administradores pueden bloquear/desbloquear remotamente con /v1/admin/lock y /v1/admin/unlock, y administrar miembros con /v1/admin/members. Los datos alojados son visibles para el operador y no están cifrados de extremo a extremo. Los metadatos de solicitudes se guardan en DIR/requests.json y la auditoría encadenada por hashes en DIR/audit.jsonl.

Cadena de autorización

Los roles de bóveda son Owner, Admin, Editor y Reader. Solo Admin o superior puede emitir o delegar autorizaciones; emitir requiere una bóveda desbloqueada, sin elevación de terminal, aunque aprobar solicitudes de rol sí requiere elevación. El alcance no puede superar el rol del emisor ni su autorización superior; el destinatario no puede tener un rol superior al emisor y center-admin no puede ser destinatario. La profundidad máxima de delegación es 2. El alcance omitido es read, no allow_all. El daemon local y Center alojado admiten como máximo 10000 autorizaciones válidas simultáneas.

Las solicitudes de permiso pueden difundirse a todos los aprobadores elegibles o dirigirse a uno con --approver; se pueden aprobar o rechazar, pero nadie puede decidir sobre su propia solicitud. La aprobación no devuelve tokens: el solicitante debe reclamarlos una sola vez mediante memories request claim VAULT ID, memories center request claim ID, MCP request_claim o POST /v1/requests/{id}/claim. Cada solicitante admite hasta 20 solicitudes pendientes por bóveda y cada bóveda hasta 200; Center devuelve HTTP 429 al superar el límite. Las pendientes y las aprobadas sin reclamar caducan tras 7 días; las finalizadas se conservan 30 días.

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

Eliminar un miembro revoca en cascada sus autorizaciones emitidas, mediante invalidación por generación del miembro. Solo se persisten hashes de las autorizaciones y el registro de auditoría forma una cadena de hashes. Consulta Autorización, en inglés.

Elegir el idioma

El móvil tiene menús de idioma en la pantalla de bloqueo y en la interfaz de la bóveda. Por defecto sigue el sistema y las selecciones manuales se conservan tras reiniciar.

La prioridad de CLI es --lang, MEMORIES_LANG, idioma guardado y después la primera variable no vacía entre LC_ALL, LC_MESSAGES y LANG. En Windows también se consulta el idioma del sistema operativo si faltan esas variables. Las configuraciones regionales no reconocidas vuelven al inglés. Se reconocen zh-CN y fr_FR.UTF-8.

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

El argumento posterior a language puede omitirse para mostrar el idioma guardado y el efectivo. system borra la selección y vuelve a seguir el sistema. El idioma guardado se distingue por --home y no necesita daemon. Los nombres de comandos, opciones, campos JSON, códigos de error y USE y APPROVE no se traducen. El contenido del usuario tampoco.

Daemon remoto (HTTP/WebSocket / RPC mediante relay)

El listener HTTP/WebSocket opcional autenticado por token y el RPC mediante relay WSS utilizan las mismas tramas JSON binarias WebSocket (AuthFrame seguido de Wire), coherentes con el protocolo local IPC service::Request. RPC ejecuta comandos sobre el almacenamiento del host remoto sin crear una copia de la bóveda en el invocador. Para intercambiar copias utiliza sync; para sincronizar mediante colas persistentes de objetos en OneDrive/Google Drive, usa cloud sync PROVIDER. Tanto al transportar RPC como bóvedas completas, el relay no es un repositorio de activos sin conexión. Los tokens del listener solo pueden proporcionarse mediante opciones o variables de entorno, nunca en TOML. HTTP/WS sin cifrar no necesita certificado por defecto; activa HTTPS/WSS con --tls-cert / --tls-key cuando lo necesites. Tras desbloqueo/elevación remotos, el daemon de escritorio ofrece las mismas operaciones completas que IPC local, con espacios de elevación ws:remote / relay:remote; Share móvil sigue respetando la lista de denegación FFI. Consulta remote-daemon.md.

El relay también reenvía webhooks de automatización persona: POST /v1/persona/{room}/{vault}/{persona}/automation/trigger. El cuerpo y token webhook son los mismos del daemon; el relay solo los reenvía al host conectado, sin realizar POST salientes.

Opciones TLS globales: --ca-file PATH (MEMORIES_CA_FILE) añade una CA PEM a los clientes TLS salientes; --insecure omite la validación del certificado y del nombre de host pero sigue utilizando TLS. Solo para desarrollo o entornos autofirmados; prefiere --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

Selección y cambio de modo móvil

Selecciona un modo en el primer inicio; la pantalla de selección también aparece al actualizar desde una versión sin configuración de modo. La aplicación recuerda la elección y entra directamente en ese modo la próxima vez.

Aquí, el modo Center es un servicio alojado propio y el servidor debe habilitar memories-center --data DIR. Es distinto del Center de autorización que solo emite tickets de dispositivos y permisos. En móvil no hace falta editar config.toml, establecer mode = "saas" ni desbloquear primero una bóveda local; esa configuración TOML corresponde al daemon de escritorio.

Como dirección Center, introduce solo el origen del servidor, por ejemplo https://center.example.com, sin /v1/rpc, parámetros de consulta ni usuario y contraseña. Las direcciones que no sean de bucle local deben utilizar HTTPS; localhost en el teléfono se refiere al propio teléfono. El operador proporciona el token de miembro; las operaciones dependen de su bóveda, rol, alcance y vigencia. El token administrativo del operador no sustituye directamente al de miembro para leer y escribir contenido.

Cambiar durante el uso

La flecha bidireccional de la parte superior de la pantalla principal es «Cambiar modo» y está disponible antes y después de iniciar sesión. El diálogo señala el modo actual; seleccionar otro cambia de modo y cancelar conserva la sesión actual. En el editor debes guardar o salir primero; se solicita confirmación si hay contenido sin guardar.

Cambiar de modo no carga, traslada, fusiona ni elimina datos de la bóveda. Desconectar no revoca el token en el servidor. Las direcciones y tokens de Center y SaaS se guardan por separado en el almacenamiento seguro del sistema; las conexiones antiguas solo migran al modo correspondiente: la dirección SaaS oficial va a SaaS y las demás a Center.

Funciones de cada modo

El modo independiente conserva navegación, búsqueda, edición, copias y restauración, uso compartido y conexiones a la nube para datos locales. Center / SaaS ofrecen listas de conocimiento alojado, búsqueda, detalles, edición, creación y eliminación, además de aprobación de solicitudes de autorización y administración de dispositivos emparejados. Tras conectar puedes consultar bóveda y alcance actuales y entrar en «Conocimiento alojado» para administrar contenido. La creación de tarjetas aún no ofrece etiquetas, fuentes ni relaciones; al editar tarjetas ordinarias existentes se admiten esos campos y se conservan otros metadatos. Las memorias ordinarias utilizan el editor del cuerpo; las configuraciones estructuradas, tarjetas protegidas, plantillas de tipo y tarjetas de extremo a extremo solo pueden consultarse aquí y se modifican mediante editores específicos.

La página de autorización se divide en «Pendientes» e «Historial». Antes de aprobar o rechazar puedes consultar solicitante, bóveda, alcance, duración y motivo completo y debes confirmar. Tras la aprobación, el solicitante sigue teniendo que reclamar la autorización por separado. El historial incluye decisiones de esta conexión y solicitudes aprobadas devueltas por el servidor; no es un registro completo de auditoría. Si falla la conexión, comprueba red, certificados, dirección, token de miembro y si Center propio ha habilitado almacenamiento alojado.

Modo móvil alojado (Hosted Center)

La búsqueda se ejecuta en el servidor y excluye contenido privado, credenciales y archivos. Vaciar las palabras clave devuelve la lista de conocimiento; con permiso de lectura pueden consultarse las tarjetas privadas de la lista. Las cuentas de solo lectura no muestran controles de modificación; las de solo escritura pueden crear directamente. Eliminar requiere permiso de eliminación y otra confirmación. Si falla el guardado se conserva el borrador; los detalles solo se cierran cuando el servidor confirma la eliminación. Actualmente el guardado no ofrece comprobación atómica de concurrencia basada en una versión esperada, por lo que varias personas editando la misma tarjeta pueden sobrescribir los campos más recientes entre sí.

Al actualizar la aplicación, actualiza también Center propio para proporcionar /v1/session. Si la sesión caduca o es revocada, desconecta y vuelve a conectar con un token válido; si faltan permisos, contacta con el administrador del servicio; si el servicio no está disponible o la bóveda está bloqueada, inténtalo más tarde.

Center y SaaS comparten las interfaces hosted_* de la FFI memories_call: conexión, lista y aprobación de solicitudes, lista de acceso, desconexión y hosted_rpc restringido. La conexión se valida mediante hosted_status, correspondiente a GET /v1/session, y devuelve bóveda actual, alcance, rol, caducidad y capacidades de lectura, escritura y eliminación, sin devolver el token. hosted_rpc admite listas, lectura, búsqueda, eliminación, tipos de tarjeta, creación de tarjetas de conocimiento, campos y operaciones de credenciales; put admite memory, card y credential. Consulta la lista permitida completa y las interfaces de dispositivos en Interfaces móviles alojadas. No todas las operaciones FFI tienen una página Flutter correspondiente.

En modo alojado el servidor puede leer los datos: Store se guarda cifrado en disco, pero el operador posee la contraseña de desbloqueo y puede leer el contenido alojado; la aplicación muestra «Legible por el servidor». El cliente Rust guarda en memoria los tokens activos y Flutter utiliza el almacenamiento seguro del sistema para las conexiones de cada modo. Los secretos sellados entre dispositivos tienen un límite de protección de extremo a extremo independiente; consulta la sección siguiente.

Sincronización de secretos de extremo a extremo (E2E) entre dispositivos

El contenido ordinario de Center alojado es legible por el servidor. Para secretos que el servidor no deba ver, empareja dispositivos y envía sobres sellados, cifrados con X25519 y firmados con Ed25519 del remitente; Center solo guarda claves públicas y texto cifrado.

Proceso de emparejamiento: 1. Ordenador: memories device hosted init --backend … genera la identidad del dispositivo en la custodia de claves del sistema. 2. Ordenador, con token de miembro: memories device hosted pair --vault V. Center crea una solicitud de permisos con la huella del dispositivo y devuelve un código de emparejamiento de un solo uso y el contenido QR, incluido Center id. El código caduca tras 5 minutos. El QR impreso en la terminal, stderr, también contiene el código de un solo uso y puede escanearse con el móvil; el JSON de stdout no cambia. Volver a emparejar un dispositivo activado devuelve 409; tras revocarlo puede emparejarse de nuevo con la misma clave. 3. Móvil, administrador: introduce o escanea el código para obtener la clave pública del dispositivo. Solo puede obtenerse una vez y demasiados fallos activan limitación de solicitudes. 4. El móvil aprueba mediante /v1/requests/{id}/approve y adjunta una certificación del dispositivo (attestation) firmada con su clave Ed25519. 5. Ordenador: memories device hosted claim --request-id ID reclama una sola vez la autorización del dispositivo; el token queda en la custodia de claves del sistema y Center solo almacena su hash. 6. Comparar SAS: el móvil lo muestra antes de aprobar, agrupado como 123 456. Tras aprobar, memories device hosted sas --pairing-id P en el ordenador debe mostrar los mismos dígitos; si difieren, revoca el dispositivo y repite el emparejamiento.

El escáner móvil rechaza QR que no sean códigos de emparejamiento Memories, cuyo Center id no coincida con la conexión actual o cuya huella de dispositivo no coincida. Permisos: Android CAMERA, con cámara como característica opcional, e iOS NSCameraUsageDescription. Si se deniega la cámara, se indica cómo habilitarla en ajustes del sistema y se permite introducir el código manualmente. CLI y móvil convierten los estados de Center en indicaciones de acción: 404 caducado/usado/otro Center, 409 ya procesado o emparejado, 403 sin permisos o dispositivo revocado, 422 contenido e2e rechazado y 429 demasiadas solicitudes.

Definición de SAS: los primeros 8 bytes de SHA-256("memories/device-sas/v1\0" ‖ 手机公钥 ‖ "\0" ‖ 电脑公钥 ‖ "\0" ‖ pairing_id) se convierten en entero big-endian, se calcula módulo 10^6 y se rellena con ceros hasta 6 dígitos. Una diferencia indica sustitución de claves públicas y exige revocación inmediata.

Reglas: las autorizaciones de dispositivo se vinculan al dispositivo y a la generación del miembro, con profundidad de delegación ≤ 2; los dispositivos no pueden emitir autorizaciones ni aprobar solicitudes; los cambios de miembro invalidan dispositivos y eliminan sus sobres; las tarjetas e2e: true rechazan secretos en texto plano en Center alojado; la lista de acceso incluye dispositivos; MCP ofrece device_list y sealed_reveal, que requiere intención explícita (intent: "reveal_plaintext" más motivo).

Modelo de amenazas: Center no puede leer secretos sellados, pero ve metadatos y puede retener sobres. Revocar no recupera el texto plano ya entregado a un dispositivo: tras revocar, rota el secreto en su origen.

Refuerzo E2E (P2)

• La marca e2e no puede retirarse silenciosamente: una vez que una tarjeta tiene e2e: true, se rechazan las escrituras que eliminen la marca, con 422. Solo una autorización Owner, no una de dispositivo, puede quitarla mediante una escritura sin ningún secreto.
• Parámetros OTP: un OTP sellado puede ser una semilla Base32, SHA1/6 dígitos/30 segundos, o una URI otpauth://totp/... completa. sealed-get --otp respeta algorithm (SHA1/SHA256/SHA512), digits (6/8) y period (30/60). device hosted pair imprime el QR de emparejamiento en stderr de la terminal.
• Volver a cifrar tras revocar: revocar un dispositivo elimina sus sobres y marca las tarjetas afectadas como needs_rotation, visible en la lista sealed, /v1/sealed/rotation, la lista de acceso y la página móvil de recifrado. El texto plano ya entregado no puede recuperarse: rota primero el secreto en su origen y después selecciona «Volver a cifrar para todos los dispositivos» en el móvil; solo se envía a dispositivos actualmente aprobados y se borra la marca.
• Recuperación de identidad móvil: Center nunca guarda la identidad móvil. Al crearla por primera vez muestra un código de recuperación una sola vez: Base32 de una semilla de 32 bytes más 2 bytes de comprobación, agrupado cada 4 caracteres. Anótalo; «Restaurar con código de recuperación» restaura la misma identidad.
• Rotación de identidad: «Migrar a una nueva clave móvil» genera otra identidad y envía un registro de rotación firmado por las claves antigua y nueva. Solo pueden enviarlo miembros administradores y algún dispositivo debe confiar ya en la clave antigua. La CLI fija la clave pública del móvil aprobador en el primer uso (hosted-device-trust.json) y solo acepta firmantes alcanzables desde esa raíz mediante una cadena de rotaciones verificada.
• Almacenamiento por hardware: la semilla móvil se guarda con las opciones incorporadas más fuertes de flutter_secure_storage: llavero iOS/macOS passcode, solo local, sin sincronización y con código del dispositivo; Android Keystore con envoltura y exigencia de biometría o credencial del dispositivo, resetOnError: false. Límite: al firmar o cifrar, la semilla debe entrar en la memoria de la aplicación, pues Secure Enclave/StrongBox no admite X25519/Ed25519; solo se protege el almacenamiento en reposo.
• Registro de transparencia: Center mantiene un registro de dispositivos de solo anexado y enlazado por hashes para emparejamiento, aprobación, rotación de identidad y revocación, GET /v1/devices/log. memories device hosted log --verify verifica la cadena, todas las firmas y que el registro prolongue la cabecera de cadena verificada anteriormente (hosted-device-log.json).

Biometría y bloqueo del dispositivo móvil

Tras desbloquear la bóveda en modo independiente, puedes activar «Desbloquear con biometría/bloqueo del dispositivo» en el menú Más. Activarlo exige primero una verificación del sistema; este interruptor de seguridad también se utiliza para operaciones sensibles como aprobaciones alojadas.

• Android: utiliza BiometricPrompt del sistema, huella o rostro, con alternativa de PIN, patrón o contraseña del dispositivo. La contraseña de bóveda necesaria para desbloqueo rápido se guarda bajo una clave vinculada a Android Keystore que exige autenticación del usuario (setUserAuthenticationRequired) y se invalida automáticamente al añadir o eliminar huellas o rostros (setInvalidatedByBiometricEnrollment(true)).
• iOS: utiliza Face ID / Touch ID, con alternativa de código del dispositivo; la entrada del llavero solo está disponible si el dispositivo tiene código configurado.
• Operaciones protegidas: desbloquear la bóveda, mostrar o copiar credenciales en texto plano, utilizar tarjetas protegidas o generar OTP, aprobar dispositivos emparejados, aprobar solicitudes alojadas, sellar (seal) y volver a sellar (re-seal).
• Cambios biométricos: la aplicación informa explícitamente cuando se invalida la clave, sin eliminar bóveda ni datos; verifica con la credencial del dispositivo e introduce una vez la contraseña de la bóveda para recrear la clave.
• Sin biometría o con el interruptor desactivado: si el dispositivo no dispone de biometría/bloqueo utilizable o el interruptor está desactivado, se mantiene el proceso por contraseña. Desactivarlo elimina la información de desbloqueo rápido guardada.

Crear contenido en móvil

Las nuevas memorias, credenciales y entradas del centro alojado comparten editor: permite importar archivos con el nombre de archivo como título predeterminado editable; los contenidos de configuración como .env cambian automáticamente a edición multilínea monoespaciada, también seleccionable manualmente. El nombre puede dejarse vacío al principio; al guardar se deduce primero del archivo o de la primera línea no vacía y solo se solicita si sigue vacío.

Las tarjetas de conocimiento usan un formulario de pantalla completa con botón Guardar fijo abajo. «Editar cuerpo» abre el editor compartido, con importación de archivos, escritura manual y escaneo. Memorias y tarjetas solo se cierran tras guardar correctamente; los fallos conservan el borrador para reintentar y se impiden envíos duplicados. Importar sobre un cuerpo existente y abandonar contenido sin guardar requieren confirmación. Los borradores solo viven en memoria y no se recuperan tras el bloqueo en segundo plano. Al editar tarjetas independientes y tarjetas ordinarias alojadas se conservan etiquetas, fuentes, relaciones y campos personalizados; la creación alojada solo ofrece metadatos aceptados por su interfaz actual.

Credenciales con múltiples campos

Una credencial puede guardar varios campos independientes, todos opcionales: usuario/cuenta, contraseña, OTP (URI otpauth:// o semilla base32 y parámetros), API Key, URL, notas y campos personalizados que pueden marcarse secretos. Contraseña, OTP, API Key y campos personalizados secretos solo se guardan en el cuerpo cifrado; usuario, URL, notas y campos personalizados no secretos pueden verse directamente.

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

Los valores secretos solo se introducen mediante entrada oculta, nunca como argumentos de línea de comandos. Las credenciales antiguas de un solo campo siguen siendo legibles: otpauth:// o títulos que empiecen por OTP: se asignan a OTP; las que tengan autenticación HTTP o hosts permitidos a API Key; el resto a contraseña. Al modificarlas por primera vez mediante credential set, o ejecutar credential migrate, se convierten al formato estructurado; las versiones antiguas permanecen en el historial, sin pérdida de datos. Las funciones anteriores que utilizan un único secreto, como inyección HTTP, enlaces de ejecución y copia sin --field, utilizan el «secreto principal»: contraseña primero, después API Key, OTP y el primer campo personalizado secreto.

Credenciales con múltiples campos: MCP, centro alojado y sincronización de extremo a extremo

• MCP credential_fields, con permiso de lectura, solo devuelve campos no secretos y nombres de campos secretos; credential_reveal, con autorización allow_all, requiere intent: "reveal_plaintext" y motivo, y devuelve y audita cada campo por separado.
• Centro alojado: de las credenciales de extremo a extremo (e2e), el centro solo guarda información descriptiva; los campos secretos solo existen en sobres sellados de dispositivos.
• Dispositivos emparejados: memories device sealed-get --vault V --card C --field password --reveal; --otp genera códigos de verificación.
• Móvil: las credenciales nuevas utilizan un formulario por secciones, acceso, códigos de un solo uso, API, más y campos personalizados, todos opcionales. Copiar campos secretos y consultar códigos en tiempo real con cuenta atrás requiere verificación de desbloqueo del sistema.