Memories

Repositorio: https://github.com/mbcc2006/memories. La CLI es memories, el relay es memories-relay y la biblioteca nativa es memories_ffi.

Memoria, archivos privados y credenciales cifrados bajo el control del cliente, con una CLI en Rust, un cliente Android/iOS, un servidor MCP local y un relay WebSocket que funciona únicamente en memoria.

Versión de desarrollo, versión de formato 1. Este repositorio incluye código ejecutable y pruebas de regresión de seguridad. No ha pasado por una revisión independiente de seguridad criptográfica o de aplicaciones. Consulte SECURITY.md para conocer las garantías, los límites de confianza y las limitaciones actuales.

Cómo se integra todo

En el uso independiente, Memories mantiene un almacén local cifrado en cada dispositivo. Úselo para guardar conocimiento que se pueda buscar, llevar una persona de IA entre clientes o usar archivos privados y secretos mediante una autorización deliberada. El almacenamiento en la nube conserva texto cifrado; el relay solo conecta pares que están en línea. Ninguno sustituye a un cliente autorizado.

La aplicación móvil también ofrece los modos Center (su servidor autohospedado) y SaaS (https://memories.ivjn.us). Estos modos usan un almacén hospedado separado cuyo operador puede leer el contenido. Elegir o cambiar de modo no sube, mueve ni fusiona una biblioteca local existente. Consulte los modos móviles.

Memories Web se conecta a su Center hospedado existente para gestionar memorias, tarjetas y archivos en un navegador. Las nuevas compilaciones de Center también lo sirven en /app/. Consulte la guía del cliente web para conocer los tokens de acceso, los orígenes permitidos y las operaciones compatibles. La API SaaS hospedada está disponible en https://memories.ivjn.us; use un token de miembro emitido para ese servicio.

unlock habilita el trabajo ordinario autorizado en el almacén. memories sudo añade una sesión de corta duración para contenido privado, archivos, credenciales y gestión sensible; no otorga derechos de administrador del sistema operativo ni elude los permisos de las bóvedas. Una autorización MCP ordinaria con alcance de bóveda es una capacidad de IA separada y limitada, no la autoridad sudo del terminal. El acceso desatendido es una capacidad de solo lectura separada y opcional que puede exponer contenido privado y valores secretos.

Empiece aquí

Para el desarrollo, consulte las directrices del repositorio, la arquitectura y los resultados de validación.

Chino simplificado: Descripción del producto, Instrucciones de uso, Documentación técnica.

Sitio de presentación del proyecto: website/, sitio estático en inglés/chino con instrucciones de despliegue en Cloudflare Pages.

Compilar y ejecutar

Instale Rust 1.88 o posterior y la cadena de herramientas C de la plataforma (SQLite se compila desde el código fuente).

cargo build --workspace --locked
cargo test --workspace --locked
cargo clippy --workspace --all-targets --locked -- -D warnings
cargo install --path crates/cli --locked

Inicie memories daemon en otro terminal. Atiende únicamente al usuario actual del sistema operativo mediante una canalización con nombre en Windows o un socket Unix en Linux/macOS. Use un directorio de datos dedicado con --home PATH o MEMORIES_HOME; el valor predeterminado es el directorio de datos de aplicaciones del sistema operativo. No apunte --home a una carpeta existente de uso general: sus permisos se restringen para proteger el servicio local.

Inicio rápido local

Con memories instalado y el daemon en ejecución, use un segundo terminal interactivo. Para un almacén independiente nuevo:

memories init --name laptop
memories vault create Personal
memories vault list

Cree un archivo UTF-8 llamado notes.md con una nota breve que contenga "project". Sustituya VAULT_ID a continuación por el id devuelto por vault create o vault list y ejecute:

memories memory put VAULT_ID --title "Project notes" --input notes.md
memories memory search VAULT_ID "project"
memories memory grep VAULT_ID 'project|release' -i -n

memory grep compara una expresión regular con cada línea descifrada del cuerpo de los documentos de memoria ordinarios de la bóveda seleccionada. Imprime DOCUMENT_ID:LINE, o DOCUMENT_ID:LINE_NUMBER:LINE con -n / --line-number; -i / --ignore-case ignora las diferencias entre mayúsculas y minúsculas. Se excluyen documentos privados, versiones en conflicto, tarjetas, archivos y credenciales, como el contenido privado en la búsqueda ordinaria. Si no hay coincidencias, no se produce salida.

Sustituya ASSET_ID por el id de la nota guardada. Para FROM_REVISION, use el campo revision devuelto por history; la comparación muestra las diferencias entre esa revisión y la cabecera actual:

memories memory read VAULT_ID ASSET_ID
memories memory history VAULT_ID ASSET_ID
memories memory diff VAULT_ID ASSET_ID FROM_REVISION
memories lock
memories unlock

En visitas posteriores, use unlock, no init. Si este es un dispositivo nuevo que se une a una identidad existente, emparéjelo antes de crear bóvedas. Para un almacén personalizado, pase el mismo --home PATH al daemon y a todos los comandos del cliente.

Descubra las tareas con memories --help y profundice con memories memory --help o memories memory put --help. Añada --lang zh para obtener ayuda en chino, por ejemplo memories --lang zh memory put --help. La ayuda no requiere un daemon.

Las contraseñas se leen de un terminal interactivo sin mostrarlas. No existe un argumento de contraseña ni una variable de entorno para contraseñas. Las contraseñas locales y de copias de seguridad no tienen restricciones de longitud a nivel de aplicación, incluida la entrada vacía; la confirmación de contraseña y la autenticación siguen siendo obligatorias. Los comandos emiten JSON versionado; los comandos fallidos devuelven un código de salida distinto de cero. Las claves públicas y las huellas de los dispositivos son visibles deliberadamente; los comandos ordinarios no imprimen claves privadas ni valores de credenciales. Las lecturas deliberadas y desatendidas de credenciales son una excepción descrita en CLI/MCP desatendido.

Daemon remoto (HTTP/WebSocket / RPC del relay)

La escucha opcional HTTP/WebSocket autenticada mediante token y el RPC del relay WSS transportan el mismo protocolo enmarcado service::Request que el IPC local (con todas las funciones en escritorio tras unlock/sudo; Share móvil mantiene la lista de denegación de FFI). Use memories daemon --listen http://127.0.0.1:7900 (opcionalmente --tls-cert / --tls-key para HTTPS/WSS). RPC ejecuta operaciones en el almacén del host; no sincroniza una réplica local. Consulte daemon remoto para conocer las opciones de escucha/cliente, los riesgos residuales y Share móvil.

Los Centers de autorización opcionales pueden prohibir la inicialización autónoma local y distribuir tickets de inscripción/autorización MCP a los endpoints. memories-center --data DIR además ejecuta una bóveda hospedada completa: controla los daemons que tienen una entrada Center con mode = "saas", el operador puede desbloquearla remotamente y los miembros se gestionan en Center.

Cadena de autorización

Los roles de las bóvedas son Owner, Admin, Editor y Reader. Solo Admin u Owner pueden emitir o delegar autorizaciones; la emisión necesita una bóveda desbloqueada pero no elevación en el terminal, mientras que aprobar una solicitud de rol sí requiere elevación. Una autorización queda limitada por el rol del emisor (y cualquier autorización superior), el destinatario no puede tener un rol superior y center-admin no puede ser destinatario. La profundidad de delegación es como máximo 2. Omitir el alcance significa read, no allow_all. Las solicitudes de permisos se envían a todos los aprobadores elegibles o a miembros --approver específicos; nadie decide sobre su propia solicitud. La aprobación no devuelve un token: el solicitante lo reclama una sola vez (memories request claim, memories center request claim, MCP request_claim o POST /v1/requests/{id}/claim). Límites: 20 solicitudes pendientes por solicitante y bóveda, 200 por bóveda (HTTP 429 en Center), TTL de 7 días para solicitudes pendientes, retención de 30 días y como máximo 10,000 autorizaciones activas tanto en el daemon como en un Center hospedado. memories access list VAULT muestra los miembros por nivel, los dispositivos y las solicitudes pendientes y aprobadas sin reclamar; memories grant list VAULT enumera las autorizaciones. Eliminar un miembro revoca sus autorizaciones en cascada (generación por miembro); las autorizaciones se conservan únicamente como hashes y el registro de auditoría está encadenado mediante hashes (Center: DIR/audit.jsonl). Consulte autorización.

El chat de persona (memories persona chat send|list|history|mark-read) activa hooks de automatización chat_message; los webhooks de automatización entrantes también son accesibles mediante memories-relay en POST /v1/persona/{room}/{vault}/{persona}/automation/trigger (consulte persona, daemon remoto).

Compilar y empaquetar para Linux

En Debian/Ubuntu (incluido Ubuntu en WSL2), instale Rust 1.88+ y las dependencias de compilación nativa:

sudo apt-get update
sudo apt-get install -y build-essential pkg-config libssl-dev python3 git
bash scripts/build-linux.sh
# Optional development build:
bash scripts/build-linux.sh --debug

El script compila el espacio de trabajo Rust para el destino GNU del host: x86_64 o aarch64. Las salidas de release están en target/<host-target>/release/ (o en el directorio de destino configurado de Cargo); las de depuración usan debug/. No se necesita el SDK de Flutter. Linux admite la CLI, el daemon, el relay, la biblioteca FFI y memories webui; la bandeja nativa actualmente solo está disponible en Windows/macOS.

Desde una copia de trabajo limpia y confirmada en Git, cree un archivo de distribución de Linux:

bash scripts/package-linux.sh

Esto recompila los binarios de release y escribe un .tar.gz, BUILD-INFO.json, SHA256SUMS y una configuración de ejemplo en dist/vVERSION-linux-ARCH/. El archivo incluye memories, memories-relay, libmemories_ffi.so, la cabecera C, documentación y licencias, conservando los permisos de ejecución. No se sobrescriben directorios de salida existentes. El flujo manual Build desktop packages también compila y sube un paquete Linux x86_64.

Estas son compilaciones nativas GNU/Linux, no binarios estáticos ni compilados para otra plataforma. Use un entorno de ejecución glibc/OpenSSL compatible; compile en la distribución más antigua que pretenda admitir. Se necesita ca-certificates para TLS del sistema y xdg-utils para abrir el panel en un navegador de escritorio. Copiar credenciales al portapapeles requiere además wl-clipboard (Wayland) o xclip (X11). Los pesos del modelo se instalan por separado con memories rag model-install.

Configuración

Ejecute memories config init para crear una configuración TOML, memories config path para localizarla y memories config show para inspeccionar los ajustes efectivos. La distribución incluye memories.example.toml con opciones de directorio de almacenamiento, relay y escritorio. Seleccione otro archivo con --config PATH o MEMORIES_CONFIG. Las opciones de la CLI tienen prioridad sobre las variables de entorno, después sobre la configuración y finalmente sobre los valores predeterminados. Consulte la guía de configuración.

Bandeja del escritorio y panel de estado

En Windows, haga doble clic en memories-tray.exe en el directorio de la distribución extraída. En macOS, abra la aplicación empaquetada Memories.app o use la línea de comandos:

memories tray
memories webui

La bandeja/barra de menús muestra el estado del daemon y de las bóvedas, abre la WebUI local y puede iniciar el daemon. El panel informa del estado de bloqueo, el número de bibliotecas, los recuentos de conexiones y las colas de sincronización en la nube sin mostrar contenido almacenado. --home selecciona el mismo almacén que la CLI; --no-open mantiene cerrado el navegador al iniciar. Inicialice/desbloquee mediante la CLI como de costumbre. Consulte la guía de escritorio para conocer el comportamiento y el empaquetado.

Idiomas

El cliente móvil y la CLI admiten inglés (en), chino simplificado (zh), japonés (ja), alemán (de) y francés (fr). El menú de idioma móvil está disponible en la pantalla de bloqueo y en la biblioteca. Sigue el sistema de forma predeterminada y recuerda una elección manual entre reinicios.

memories --lang zh --help
memories cloud login --lang ja --help
memories --lang de status
memories language zh       # Remember this language
memories language          # Show saved and effective language
memories language system   # Follow the system again

La selección de idioma de la CLI usa --lang, después MEMORIES_LANG, después una preferencia de idioma guardada y finalmente la primera variable no vacía entre LC_ALL, LC_MESSAGES o LANG. La preferencia se guarda por --home / MEMORIES_HOME y funciona sin daemon. En Windows también usa el idioma del sistema operativo cuando no está definida ninguna de esas variables. Los idiomas no compatibles recurren al inglés; se aceptan valores de entorno como fr_FR.UTF-8 y zh-CN. Los comandos, nombres de opciones, campos JSON, códigos de error y palabras de confirmación USE y APPROVE permanecen estables. El contenido del usuario no se traduce. Los diagnósticos de bajo nivel sin traducción conservan sus detalles originales con un resumen de error localizado. Consulte la guía de localización para el mantenimiento.

IDs cortos

Las solicitudes de CLI, MCP y móvil usan IDs hexadecimales cortos sin adornos, normalmente de seis caracteres (por ejemplo, 0b0668). Los IDs no expresan tipo ni clasificación y no tienen prefijos ni guiones bajos. Use directamente los IDs devueltos por vault list, card list, card search o el historial en el comando correspondiente. Se rechazan UUID largos, hashes completos de revisiones e IDs con prefijo; no hay opción de salida de IDs largos.

Los IDs existentes de ocho caracteres siguen siendo válidos. Los prefijos que colisionan se amplían automáticamente en incrementos de dos caracteres hasta 16 caracteres; se rechaza la entrada ambigua. Esto no acorta las claves de dispositivos ni las huellas de seguridad.

memories card list eb7abf
memories card search eb7abf "claude relay"
memories card read eb7abf 0b0668

Los IDs se resuelven en el ámbito de cada argumento de comando. Una colisión amplía el ID devuelto en dos caracteres, hasta 16; una entrada ambigua falla en lugar de seleccionar un objeto. Vuelva a listar o buscar después de una colisión. Los recursos eliminados permanecen en el índice de colisiones. Los IDs cortos son referencias, no autorización: siguen aplicándose unlock, sudo, los permisos de bóveda y las autorizaciones MCP.

Los registros de almacenamiento firmados conservan sus identificadores originales sin migración. No se acortan ni reescriben certificados, claves públicas, huellas de verificación, registros de auditoría ni envolturas de transporte cifradas.

Recuperación de información y RAG

La búsqueda ordinaria ahora tokeniza chino y admite múltiples palabras clave. Su índice BM25 se almacena en caché en memoria, se invalida al cambiar el contenido/la política y se borra al bloquear. La recuperación avanzada añade desplazamientos de fragmentos, puntuaciones vectoriales, fusión de rankings híbridos, reordenación ligera y reordenación aprendida opcional mediante una URL configurada. Las credenciales y el contenido privado siguen excluidos.

memories rag ingest VAULT_ID notes.md --title "Research notes"
memories rag search VAULT_ID "Chinese and English keywords" --mode bm25
memories rag model-install
memories rag index VAULT_ID
memories rag search VAULT_ID "What does this document mean?" --mode hybrid
memories rag ask VAULT_ID "Summarize the evidence"

El motor de inferencia CPU integrado ejecuta EmbeddingGemma dentro del proceso Memories; no se necesita Ollama ni otra aplicación de inferencia. Los archivos de modelo son datos públicos que se instalan una vez con model-install o se proporcionan en rag.local_model_dir. Gemini Embedding es una API en línea separada. Configure las URL seleccionadas por el cliente para embeddings remotos, generación y reordenación opcional. Se pueden configurar proxies HTTP(S)/SOCKS, tiempos de espera y reintentos limitados. Consulte la guía de RAG.

Archivos privados y credenciales

sudo es una sesión interna de autorización, no acceso de administrador del sistema operativo. Usa la misma contraseña local. La elevación dura como máximo 15 minutos, caduca después de cinco minutos de inactividad y queda limitada al proceso padre del terminal. Bloquear o reiniciar el servicio la borra. El desbloqueo ordinario caduca después de 15 minutos de inactividad.

memories sudo
memories file import VAULT_ID document.pdf
memories file export VAULT_ID FILE_ID exported.pdf
memories file exec VAULT_ID FILE_ID -- caddy run --config "{file}" --adapter caddyfile
memories credential add VAULT_ID "API token"
memories credential import VAULT_ID "SSH identity" existing-private-key
memories credential generate VAULT_ID "laptop ssh"
memories credential generate VAULT_ID "laptop ssh" --algorithm rsa --bits 4096
memories credential generate VAULT_ID "db ca" --kind tls-ca --algorithm rsa --subject memories-ca
memories credential generate VAULT_ID "db server" --kind tls --ca CA_ID --algorithm rsa --name db.example.test
memories credential public VAULT_ID KEY_ID
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
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
memories credential allow-host VAULT_ID CREDENTIAL_ID api.example.com
memories credential http VAULT_ID CREDENTIAL_ID https://api.example.com/status
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 open mysql --vault VAULT_ID --credential CREDENTIAL_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 open postgres --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 mysql --vault VAULT_ID --credential CREDENTIAL_ID --host db.example.test --user app --database appdb --no-tls
memories remote run SESSION_ID -- uname -a
memories remote run SESSION_ID --op query -- SELECT 1
memories remote propose SESSION_ID -- uname -a
memories remote approve TICKET_ID
memories remote exec TICKET_ID
memories remote close SESSION_ID
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 CREDENTIAL_ID --host db.example.test --user app --database appdb
memories proxy list
memories proxy stop PROXY_ID

Ejecutar un programa con un archivo de configuración almacenado

memories file exec VAULT_ID FILE_ID -- PROGRAM ARGS... lee un archivo autorizado y sustituye cada {file} en los argumentos del programa por una ruta absoluta a un archivo temporal. Use --revision REVISION antes de -- para seleccionar una versión histórica. Requiere el mismo desbloqueo, acceso a la bóveda y memories sudo en el terminal que la exportación de archivos. Un daemon remoto/hospedado puede proporcionar el archivo; el programa siempre se ejecuta en la máquina de la CLI, con la cuenta del usuario de la CLI.

memories sudo
memories file import VAULT_ID ./Caddyfile
# Use the returned file ID. Caddy 2 Caddyfile syntax needs an explicit adapter.
memories file exec VAULT_ID FILE_ID -- caddy run --config "{file}" --adapter caddyfile

El proceso hijo hereda el directorio de trabajo, el entorno y los flujos estándar; se devuelve su código de salida sin una envoltura JSON de éxito. No se introduce un shell y no hay límite de ejecución de cinco minutos. Ejecute el programa en primer plano. El directorio/archivo temporal son exclusivos del propietario (Unix 0700/0600; ACL del usuario en Windows) y se eliminan cuando el hijo termina o no logra iniciarse. Ctrl+C/Ctrl+Break en Windows y SIGINT/SIGTERM/SIGHUP en Unix activan el cierre, dejando diez segundos antes de finalizar forzosamente el hijo directo y limpiar. Las señales Unix se reenvían al hijo; los eventos de consola de Windows llegan a los procesos que comparten esa consola.

Esto exporta texto sin cifrar durante la vida del proceso hijo. Confíe en el programa y sus plugins: su salida no se redacta. El bloqueo/la revocación no puede recuperar la copia entregada ni detener al hijo. La finalización forzosa de Memories, un corte de energía o el cierre de una consola Windows pueden dejar el archivo temporal; eliminarlo no es un borrado seguro. No se gestionan los descendientes desacoplados. Cada invocación usa una instantánea fija de archivo llamada config; no se producen actualizaciones automáticas, recargas, expansión de plantillas ni importaciones de archivos relacionados. Las rutas relativas siguen las reglas del programa de destino, por lo que debe usar rutas absolutas para inclusiones/certificados externos y especificar el formato explícitamente cuando un programa lo deduzca del nombre de archivo.

Inyección de credenciales en procesos

La inyección de credenciales en procesos de memories run usa stdin; --env permite deliberadamente una variable de entorno. La huella SHA-256 del programa debe confirmarse o proporcionarse mediante --approve-digest. Se suprimen ambos flujos de salida del hijo. Aun así, el programa receptor puede copiar o transmitir la credencial y debe ser de confianza. Una vinculación de ejecución fija una credencial a una huella de programa para que un agente de programación pueda usarla sin la sesión sudo de su terminal. credential bind gh (sudo, escribiendo USE) resuelve gh en PATH, registra su SHA-256 y guarda la vinculación únicamente en el estado cifrado de este dispositivo; nunca se sincroniza y se borra al restaurar. Caduca después de --hours (8 por defecto, como máximo 720) y solo funciona mientras la biblioteca esté desbloqueada. run --binding gh -- ARGS ejecuta entonces el programa en el directorio actual con la credencial en la variable de entorno elegida, reproduce su salida sustituyendo cada aparición de la credencial por [REDACTED] (--suppress-output la descarta en su lugar) y termina con el código del programa. --deny WORDS rechaza comandos cuyos argumentos que no son opciones contienen esas palabras en orden; --ask WORDS hace que el hook pregunte antes de ejecutarlos. Para gh, se deniegan auth, alias y extension (también extensions y ext), y se pregunta para pr merge, repo delete y release delete, salvo que se use --no-default-rules. Las reglas comparan las palabras tal como se escriben; no se expanden los alias definidos anteriormente con gh alias set. Hasta que caduque la vinculación, cualquier programa que se ejecute con su identidad puede ejecutar el programa vinculado con la credencial; no puede leer la credencial mediante Memories. El propio programa, sus extensiones y sus procesos hijos sí pueden, así que vincule únicamente programas de confianza. Una vinculación sin --credential y --env aplica solo las reglas.

hook install --commands gh añade un hook PreToolUse a la configuración de usuario de Claude Code (tras mostrar la entrada y pedir APPROVE). Cuando Claude Code va a ejecutar gh ... en Bash o PowerShell, el hook reescribe esa palabra de comando como memories run --binding gh -- y deja intacto el resto de la línea de comandos. Se deniega con un motivo ejecutar gh dentro de $( ), acentos graves, sh -c, xargs y envoltorios similares; se permiten los cuerpos heredoc y las sustituciones usadas como argumentos (como --body "$(cat <<'EOF' ... EOF)"). La entrada canalizada o redirigida se reenvía con --stdin (hasta 16 MiB). El programa se ejecuta en el entorno del daemon, por lo que se rechaza un prefijo NAME=value gh ...; use las opciones del programa en su lugar. Los argumentos que el shell expande al ejecutar ($var, patrones glob) no pueden comprobarse con las reglas, así que el hook pregunta antes de ejecutarlos. El hook aprueba directamente un comando solo cuando consiste exclusivamente en ejecuciones vinculadas; si además ejecuta otros programas o escribe archivos, se aplica la confirmación habitual de Claude Code. Se limita el número de workers que quedan leyendo canalizaciones retenidas por descendientes persistentes de un programa vinculado, y se rechazan nuevas ejecuciones vinculadas mientras queden demasiados. Las propias reglas de permisos de denegación y consulta de Claude Code siguen aplicándose, pero pueden ver el comando reescrito, así que mantenga los subcomandos sensibles en las reglas de la vinculación. Los programas vinculados se ejecutan fuera del bloqueo del servicio, de modo que un gh run watch prolongado no bloquea otros clientes; el límite de cinco minutos sigue aplicándose.

La interfaz HTTPS envía un token Bearer únicamente a un host configurado mediante HTTPS/443, no sigue redirecciones ni hereda la configuración de proxies y devuelve solo el código de estado para evitar reflejar una credencial en el cuerpo de una respuesta. Las sesiones SSH, FTP, TCP, MySQL, Redis y PostgreSQL gestionadas por el daemon mantienen los secretos en el servicio. Cada instrucción se propone, se aprueba con APPROVE y después se ejecuta una sola vez en la sesión activa. remote run realiza los tres pasos; los scripts pueden separarlos con remote propose (pone un ticket en cola), remote approve (sudo, un solo uso) y remote exec (el mismo llamante elevado). SSH acepta una credencial de contraseña, una clave privada OpenSSH importada (credential import) o una clave generada dentro de la bóveda (credential generate). Generate nunca imprime la clave privada; credential public devuelve únicamente la clave pública SSH o el certificado TLS. Opcionalmente, adjunte una segunda credencial de certificado OpenSSH (--certificate). SSH también requiere una huella fijada de clave de host obtenida de remote probe. Las sesiones MySQL, Redis y PostgreSQL usan TLS de forma predeterminada con verificación del nombre de host. Redis y PostgreSQL usan rustls con raíces webpki; MySQL usa la biblioteca TLS de la plataforma. --tls-ca añade una CA PEM almacenada en una credencial de bóveda; sigue siendo distinta del --ca-file PATH global (MEMORIES_CA_FILE), que añade un paquete de CA PEM del sistema de archivos para WSS del daemon/relay y clientes HTTPS/bases de datos salientes. Establezca estas opciones en el proceso que realiza la conexión (inicie el daemon con ellas para operaciones ascendentes gestionadas por el daemon). El --insecure global omite la verificación del certificado y del nombre de host sin desactivar TLS: peligroso, solo para desarrollo/certificados autofirmados; prefiera --ca-file. Los --tls-cert / --tls-key del servidor no cambian. Consulte los ejemplos de TLS del cliente. Pase --no-tls para desactivar TLS de bases de datos. MCP no puede usar esta vía. Las operaciones de archivos usan FTP; las sesiones SSH aprobadas aceptan únicamente exec.

Proteger secretos en documentos wiki

En la aplicación, abra el menú de una memoria/tarjeta y elija Proteger secreto en documento (chino: 替换资料中的密钥). Asigne un nombre a la referencia (por ejemplo API_KEY), introduzca después el secreto exacto mediante entrada oculta y autorice la operación. Todas las coincidencias exactas en el cuerpo de ese documento se convierten en {{secret:API_KEY}}; el valor se guarda como una credencial cifrada. Las lecturas ordinarias, la búsqueda y MCP ven únicamente la referencia.

Elija Copiar secreto (复制密钥) en el menú de un documento o una credencial. En un documento con varias referencias, seleccione primero la etiqueta. Confirme y autorice para copiar su valor actual al portapapeles del sistema sin mostrarlo.

La CLI proporciona las mismas operaciones (use IDs cortos de list o search):

memories sudo
memories memory protect-secret VAULT_ID DOCUMENT_ID API_KEY
# For a knowledge card, use: 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

El comando de sustitución solicita el secreto; no ponga secretos en los argumentos ni en los nombres de referencia. Las etiquetas aceptan 1-64 letras ASCII, dígitos, guiones bajos o guiones y no deben estar ya usadas en ese documento. Copiar una referencia de documento requiere --label, incluso si hay una sola referencia. Copy devuelve únicamente el estado de copia ("copied": true). Windows usa el portapapeles nativo, macOS usa pbcopy y Linux requiere wl-copy (Wayland) o xclip (X11). Las tarjetas protegidas de cuenta/token/env/OTP también pueden copiarse directamente; las copias OTP devuelven la semilla, no un código de un solo uso.

La sustitución afecta únicamente al cuerpo actual del documento. Las versiones firmadas antiguas, las copias de seguridad, otros documentos y las copias compartidas conservan su contenido anterior; revoque o rote las claves expuestas con su proveedor. El contenido del portapapeles permanece después del bloqueo y puede ser visible para otras aplicaciones o el historial del portapapeles del sistema operativo. Bórrelo después de usarlo. Esta función no descubre secretos automáticamente ni rota claves. Actualice todos los clientes antes de sincronizar documentos que contengan referencias a secretos. Consulte la guía completa para conocer las condiciones de rechazo, la edición y actualización de credenciales, los requisitos de plataforma y la resolución de problemas del portapapeles.

Proxies SSH y de bases de datos sin contraseña

memories proxy start abre una escucha en 127.0.0.1 después de sudo en el terminal y de las comprobaciones de la lista de hosts permitidos de la credencial. Devuelve un id, una dirección listen y un command listo para usar. Ejecute ese comando en el terminal del agente en la máquina del daemon; no se devuelve ninguna contraseña almacenada ni clave privada. La cuenta, el host y la base de datos inicial ascendentes se seleccionan con los argumentos de inicio del proxy. Un proxy autoriza comandos para esa cuenta sin aprobación individual de cada comando.

memories sudo
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

Use credential allow-host VAULT_ID CREDENTIAL_ID HOSTNAME para autorizar primero el destino de una credencial. Verifique mediante un canal de confianza una huella SSH obtenida con remote probe antes de proporcionar --host-key. Los proxies SSH reenvían solicitudes exec, shell, PTY y de subsistemas; las claves de host ascendentes siguen fijadas. Las claves de host SSH locales son efímeras, de modo que el comando devuelto desactiva la persistencia de la clave de host solo para el endpoint local.

Las conexiones ascendentes de bases de datos usan TLS verificado de forma predeterminada, con --tls-ca CA_ID opcional. El tramo local de la base de datos es loopback sin cifrar. PostgreSQL admite autenticación SCRAM-SHA-256, MD5 y mediante contraseña. MySQL admite mysql_native_password y caching_sha2_password; la autenticación completa de contraseña SHA-256 requiere TLS. No están implementados el reenvío de cancelaciones/opciones de inicio de PostgreSQL ni la compresión de MySQL. Los nombres de inicio de sesión locales y las solicitudes de base de datos inicial no sustituyen la cuenta/base de datos ascendente configurada.

Cualquier proceso que pueda alcanzar el puerto local puede usar su cuenta remota autorizada. Mantenga el puerto local. El bloqueo, el bloqueo automático de la bóveda por inactividad, proxy stop y el cierre del daemon cierran las escuchas y las conexiones existentes. Los proxies también caducan después de 30 minutos incluso si se utilizan, con un máximo de cuatro proxies y 16 conexiones por proxy. MCP no puede iniciar, listar ni detener proxies; un agente usa su cliente de terminal ordinario después de que el usuario inicie uno.

Capturar contraseñas y la salida de comandos

memories catch (también memories credential catch) captura un secreto UTF-8 y lo guarda como una credencial cifrada. Ejecute primero memories sudo en el mismo terminal. Sin una opción de origen, solicita entrada oculta, como credential add:

memories sudo
memories catch VAULT_ID "Database password"

Use --stdin para una canalización o un archivo redirigido. Estos ejemplos funcionan en Windows CMD; secret-tool representa su propio programa que emite el valor:

secret-tool.exe | memories catch VAULT_ID "Database password" --stdin --regex "password=([^\r\n]+)"
memories catch VAULT_ID "API token" --stdin --json-pointer /token < response.json
memories catch VAULT_ID "API token" --exec secret-tool.exe --json-pointer /token -- issue --format json

--exec PROGRAM -- ARGS... inicia directamente el programa especificado y captura stdout. Cierra stdin del hijo y suprime stderr. Para un script CMD, use --exec cmd.exe -- /d /c script.cmd; los operadores del shell requieren un shell elegido deliberadamente. Este modo no admite programas externos interactivos que necesiten un terminal; use entrada oculta o un comando de salida no interactivo en su lugar.

Sin selector, la captura conserva el texto completo salvo un LF/CRLF final. Una regex debe coincidir exactamente una vez; se guarda su único grupo de captura, o la coincidencia completa si no tiene grupos. Use (?:...) para agrupaciones adicionales. --json-pointer selecciona una cadena JSON (por ejemplo /credentials/password); no puede combinarse con --regex. Los objetos JSON deben tener claves únicas, incluidos los objetos anidados y equivalentes escapados como password y pass\u0077ord. Se rechazan sin guardar los valores vacíos, UTF-8 inválido, coincidencias ambiguas, claves duplicadas y comandos fallidos. Use --id CREDENTIAL_ID para sustituir una credencial.

La entrada está limitada a 1 MiB. Los comandos agotan el tiempo de espera después de 30 segundos; establezca --timeout entre 1-300 segundos si es necesario. Si se agota el tiempo o la salida es excesiva, capture finaliza su hijo directo; no proporciona contención del árbol de procesos. Stdin canalizado espera EOF y no tiene tiempo de espera. La salida correcta contiene el ID de la credencial, nunca el valor capturado. Use memories run u operaciones HTTP autorizadas para usarla. No ponga secretos reales en argumentos de comandos, patrones regex ni títulos. Capture no borra los archivos de origen, el historial del shell ni los registros producidos por el programa de origen.

Dispositivos, miembros y sincronización

Autorización de cuentas en la nube

Autorice OneDrive o Google Drive en este dispositivo con su propia aplicación OAuth registrada. Inicie el daemon actual, desbloquee la biblioteca y ejecute sudo en el mismo terminal antes de iniciar sesión:

memories sudo
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 logout onedrive

El inicio de sesión abre el navegador y valida un callback local con PKCE/state. Los tokens se guardan en el estado cifrado local del dispositivo y se excluyen de las copias de seguridad/el intercambio entre dispositivos. Status nunca imprime tokens. Logout elimina la autorización local; el consentimiento del proveedor se gestiona por separado. memories cloud sync sube y descarga objetos inmutables de texto cifrado mediante la carpeta de aplicación de OneDrive o Google Drive conectada después de renovar los tokens. La aplicación móvil proporciona controles de conexión a la nube y sincronización en primer plano; se requiere registrar un cliente OAuth nativo. Consulte la configuración móvil de la nube.

Consulte docs/cloud-authorization.md para conocer el registro de proveedores, las URI de redirección, --no-browser, la caducidad y la resolución de problemas.

Emparejamiento de dispositivos y transferencia de bóvedas

Inicialice el dispositivo nuevo con su propia contraseña y ejecute:

memories sudo
memories device invite request.json

Transfiera la solicitud a un dispositivo existente. Compare la huella completa de la invitación directamente con el dispositivo solicitante antes de aprobarla:

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

El comando de aprobación devuelve su clave pública de dispositivo. Verifique esa clave mediante un canal de confianza antes de aceptar la respuesta en el dispositivo nuevo. Ejecute sudo en el mismo terminal del dispositivo nuevo antes de aceptar:

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

Las solicitudes caducan después de diez minutos y son de un solo uso. Un dispositivo recién inicializado no debe tener bóvedas antes de unirse a una identidad existente. Cada dispositivo conserva su propia clave privada de transporte y clave de firma de dispositivo; la autoridad de firma de la identidad de usuario se transfiere únicamente dentro de la aprobación cifrada. Un certificado firmado por el usuario por sí solo no otorga acceso a las bóvedas: la lista firmada de dispositivos permitidos de la bóveda también debe aprobarlo.

Para una persona diferente, apruebe su solicitud para una bóveda concreta:

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 device revoke VAULT_ID DEVICE_PUBLIC_KEY

Los propietarios gestionan los administradores y la propiedad; los administradores gestionan los miembros ordinarios; los editores escriben recursos; los lectores leen y usan recursos. La revocación de dispositivos es por bóveda. Aplíquela a todas las bóvedas afectadas. Nunca suponga que eliminar a un miembro borra sus copias existentes.

El intercambio de archivos cifrados funciona sin relay:

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

Para una transferencia en línea, ejecute memories-relay detrás de un proxy inverso TLS y cree una sala con memories sync room. En el receptor y después en el emisor:

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

El relay no pone paquetes en cola para dispositivos sin conexión. Un envío correcto significa que se entregó un paquete al relay, no que un par lo verificó/importó; el receptor informa por separado del éxito de la importación. sync export/import y sync send/receive del relay son transferencias deliberadas de bóvedas completas, no sincronización incremental automática en la nube. cloud sync PROVIDER, en cambio, intercambia objetos inmutables de texto cifrado mediante colas duraderas en la nube; la verificación con cuentas reales sigue pendiente. RPC del relay es algo diferente: llama al daemon remoto sin importar su bóveda al almacén del cliente. Un cliente siempre en línea propiedad del usuario puede mantener una réplica, pero ese cliente es un endpoint de confianza, no un servidor de almacenamiento no confiable.

Cada creación/actualización escribe una nueva revisión firmada en el DAG de la bóveda (memoria, tarjetas de conocimiento/Brain, metadatos de tarjetas protegidas, archivos y credenciales). Use memory history / card history / file history para listar revisiones (revision, marca de tiempo, autor, cabecera, resumen). Obtenga una revisión con read --revision y compare con memory diff / card diff / file diff (texto unificado sobre título, metadatos estructurados y cuerpo; las diferencias de archivos omiten las cargas binarias; los cuerpos secretos de las credenciales nunca se devuelven). Las revisiones se conservan indefinidamente con la bóveda, sin poda automática. Las ediciones simultáneas de recursos permanecen como múltiples cabeceras. Use memory history y, deliberadamente, memory put --id ASSET_ID --resolve después de revisarlas. Los cambios de épocas antiguas antes desconocidos entran en sync quarantine; sync reapply firma una nueva revisión de la época actual. Las cadenas de permisos divergentes fallan de forma cerrada. Un propietario válido en ambas ramas puede revisarlas y ejecutar sync resolve-policy VAULT_ID packet.json --keep-local, y después distribuir la resolución firmada. Los conflictos que implican transferencias de propiedad incompatibles permanecen bloqueados en lugar de otorgar control unilateral a cualquiera de las partes.

Auditoría y recuperación

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

Las copias de seguridad usan una contraseña independiente. Mantenga una copia fuera del dispositivo. Para recuperar, inicie un daemon con un --home nuevo y después ejecute:

memories --home NEW_DIRECTORY restore offline-backup.memories --name replacement
memories --home NEW_DIRECTORY sudo
memories --home NEW_DIRECTORY archive list

La recuperación crea bóvedas independientes que contienen los recursos actuales y las cabeceras de conflicto conservadas. No reactiva autoridad obsoleta de bóvedas compartidas. Las versiones originales, los marcadores de eliminación y los registros de auditoría firmados permanecen en el archivo de recuperación cifrado de solo lectura (archive history, archive read, archive audit). Vuelva a unirse a las bóvedas compartidas activas mediante un miembro autorizado actual. Los valores históricos de credenciales no pueden imprimirse mediante las interfaces normales ni las de archivo.

Inyección de habilidades en clientes de IA

Instale la habilidad memories incluida para que un cliente de IA pueda descubrir cómo buscar, recuperar y guardar conocimiento de Memories, responder a partir de documentos autorizados y usar operaciones autorizadas de credenciales:

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

El valor predeterminado es la instalación para todo el usuario. --project DIRECTORY instala solo en un directorio de proyecto existente (use --project . para el directorio actual). claude apunta a Claude Code, con claude-code aceptado como alias.

~ es el directorio personal del usuario del sistema operativo, incluido %USERPROFILE% en Windows. OpenCode respeta OPENCODE_CONFIG_DIR, después un XDG_CONFIG_HOME absoluto más opencode y después el valor predeterminado anterior. Claude Code respeta CLAUDE_CONFIG_DIR. Codex usa su ubicación documentada .agents/skills, independientemente de CODEX_HOME. La instalación de proyecto ignora estas sustituciones globales. OpenCode también descubre directorios de habilidades compatibles con Claude/agentes; al usar varios clientes, mantenga el mismo contenido de la habilidad memories en todas las ubicaciones para evitar definiciones contradictorias.

La instalación es sin conexión y no requiere un daemon ni un almacén inicializado. Escribe únicamente la habilidad incluida, sin leer/exportar contenido de las bóvedas, crear autorizaciones ni modificar la configuración de MCP/clientes. --home/MEMORIES_HOME seleccionan el almacén de datos de Memories para operaciones normales, no el destino de la habilidad; la instalación no incorpora esa ruta. Configure el mismo directorio en el entorno de su cliente o comando MCP cuando use un almacén no predeterminado.

Los archivos existentes idénticos se dejan intactos. Se rechaza un SKILL.md diferente, incluida una habilidad antigua dejada por una versión anterior de Memories, salvo que se pase --force; esa opción sustituye únicamente ese archivo y conserva los archivos vecinos. Se rechazan archivos/directorios de habilidades enlazados incluso con --force. Se comprueban conflictos en todos los destinos antes de escribir y cada archivo se publica atómicamente. Un fallo posterior de E/S del sistema de archivos puede dejar destinos anteriores instalados; corrija el error y vuelva a ejecutar. --dry-run realiza las mismas comprobaciones e informa de las rutas/acciones previstas sin escribir nada; use --dry-run --force para previsualizar sustituciones.

Asegúrese de que memories esté en el PATH del cliente. Abra una sesión nueva del cliente si no descubre la habilidad inmediatamente. En Codex, invoque $memories; en Claude Code, invoque /memories; en OpenCode, pídale que cargue la habilidad memories. La instalación local de habilidades no instala habilidades a nivel de cuenta en Claude Desktop/Cowork ni en sesiones de la nube. La habilidad usa una conexión MCP ya configurada cuando está disponible; configúrela por separado como se describe a continuación.

Convenciones de descubrimiento: Codex, OpenCode, Claude Code.

Generar AGENTS.md / habilidad de persona

Escriba un AGENTS.md de proyecto (o un directorio de habilidad de estilo Cursor/Codex) que explique cómo operar Memories: bóvedas, tarjetas, persona/mundo/cosas, historial/diferencias y aspectos básicos del daemon remoto. Opcionalmente, incorpore una descripción del núcleo de una persona:

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 único archivo markdown. --layout skill escribe SKILL.md dentro del directorio de salida (o en la ruta si ya termina en .md). Cuando se omite --persona, se usa el valor predeterminado persona del cliente si está establecido. Generar con una persona lee esa tarjeta mediante el daemon (desbloquee primero). Sin una persona, la generación es sin conexión y no necesita el daemon. Use --force para sustituir un archivo existente diferente; --dry-run previsualiza el plan sin escribir.

memories inject sigue siendo el instalador separado sin conexión de la habilidad genérica incluida en las rutas de Codex / OpenCode / Claude Code.

Valores predeterminados de la CLI del cliente

Los valores predeterminados no secretos se guardan en defaults.json dentro del directorio de Memories (MEMORIES_HOME / --home), no en el texto cifrado de las bóvedas:

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

Las opciones explícitas siempre tienen prioridad. Los subcomandos de persona que toman bóveda/recurso tratan los argumentos posicionales omitidos como valores predeterminados (world-get, thing, append-event, …). persona import sigue requiriendo un ID de bóveda explícito antes de la ruta de la habilidad (orden posicional de clap).

MCP local

Esta sección describe las autorizaciones MCP ordinarias con alcance de bóveda. El servidor desatendido opcional y separado tiene un límite de lectura más amplio.

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

La autorización es una capacidad bearer local, escrita en un archivo en lugar de imprimirse. Proteja ese archivo. Las autorizaciones tienen acceso de lectura por defecto; use --scope read_write para escribir contenido ordinario o --scope read_write_delete para incluir la eliminación. --write es una abreviatura de compatibilidad de --scope read_write. Estos alcances no otorgan acceso al contenido privado, archivos, credenciales ni sudo. Configure el comando MCP stdio de su cliente de IA como memories mcp serve --grant-file ... con el mismo directorio que el daemon en ejecución. 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 de persona enumeradas en Tarjetas de persona. workflow_card crea flujos de pasos, plantillas de listas de comprobación o tareas copiadas de una plantilla, y workflow_update edita campos de listas de comprobación o avanza pasos; ambas necesitan un alcance de escritura. workflow_read y workflow_list funcionan con acceso de lectura. Cada llamada incluye el ID de la bóveda autorizada. memory_retrieve devuelve fragmentos de documentos con citas. Su modo predeterminado es BM25 local; vector y hybrid usan el proveedor de embeddings configurado del daemon. memory_ask responde a partir de esas fuentes cuando se configura una URL de generación y rechaza citas que no estaban en las pruebas recuperadas. Consulte Recuperación y RAG. Se excluyen las memorias privadas, los archivos, el acceso a credenciales, la ejecución de procesos y los cambios de miembros de las bóvedas. La emisión, listado y revocación de autorizaciones y las solicitudes de permisos son herramientas MCP separadas y no heredan sudo. El bloqueo descarta las autorizaciones en memoria; las no caducadas se reanudan tras desbloquear. Protocolo MCP: 2024-11-05. Las lecturas MCP dejan sin resolver las referencias a secretos. La herramienta card_write actual no puede actualizar tarjetas que contengan referencias a secretos porque no conserva su mapeo; edite esas tarjetas mediante la CLI o la aplicación móvil.

CLI/MCP desatendido de escritorio

La inscripción deliberada requiere consentimiento escribiendo ENABLE y desbloqueo/sudo mediante contraseña una vez para la configuración. Elija deliberadamente windows-dpapi, macos-keychain, linux-secret-service o el backend de menor protección owner-file, y después emita un archivo de cliente con alcance de bóveda. Seleccione ese archivo con unattended ... --client-file PATH o mcp serve-unattended --client-file PATH. Estos clientes pueden leer contenido ordinario/privado, archivos originales, historial y texto sin cifrar de credenciales solicitado deliberadamente, pero no pueden modificar recursos ni heredar sudo.

El inicio del daemon carga solo claves, no autorización ordinaria implícita. El lock manual inhibe de forma duradera el acceso desatendido hasta un unattended resume autorizado mediante contraseña; revoke elimina una autorización y disable elimina toda autoridad desatendida. Los almacenes gestionados por Center, los transportes remotos y los móviles no pueden usarlo. El MCP ordinario no cambia. Base64 de credenciales es codificación, no cifrado: un cliente de IA o sus registros pueden conservar el secreto. Consulte configuración, lecturas por rangos de bytes y límites de seguridad.

Tarjetas de conocimiento y protegidas

Todas las tarjetas de conocimiento admiten tipos de tarjetas y campos personalizados: nota, contacto, enlace, fragmento de código, lista de comprobación, evento y credencial, además de plantillas reutilizables de bóveda. Los campos están ordenados y se validan; los valores sensibles permanecen enmascarados salvo que se revelen deliberadamente con autorización verificada. Use memories type y memories card field, o los editores de tarjetas de Flutter y los editores restringidos de escritorio.

Las tarjetas admiten etiquetas, fuentes, alias opcional (别名), notas/observación (备注), categoría (分类), relaciones dirigidas y enlaces entrantes. El contenido ordinario de las tarjetas y los resúmenes seguros de cuentas pueden buscarse localmente; las lecturas ordinarias de tarjetas privadas requieren sudo y se excluyen de la búsqueda ordinaria y de MCP. La autoridad desatendida separada puede leer tarjetas privadas dentro de su alcance. Use --alias, --notes y --category al crear/actualizar. card list (también memories list / memories ls de nivel superior) puede omitir el ID de bóveda para recorrer 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 son tarjetas wiki/de conocimiento sencillas; brain es conocimiento estructurado con un resumen y enlaces tipados; otp significa totp+hotp); --otp es la abreviatura de --type otp. --category NAME filtra; --group-by-category agrupa la salida. El listado muestra el alias, las notas y la categoría cuando están presentes.

memories card put VAULT_ID --title "An idea" --input notes.md --tag design --alias "Design note" --notes "from workshop" --category design
memories card list VAULT_ID
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 --type account
memories card list VAULT_ID --category design
memories card list VAULT_ID --group-by-category
memories card brain VAULT_ID --title "Alice" --abstract "Product lead bridging design and eng" \
  --link CARD_A=reports-to --link "OTHER_VAULT/CARD_B=collaborates|shared roadmap" \
  --alias "Alice" --notes "org chart" --category people
memories card brain VAULT_ID --id BRAIN_ID --title "Alice" --abstract "Updated abstract" --link CARD_B=partner
memories card link 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 unlink VAULT_ID CARD_A CARD_B --relation supports
memories card delete VAULT_ID CARD_ID

card delete (como memory delete) elimina la tarjeta de las vistas actuales; el historial firmado conserva las revisiones anteriores. Eliminar tarjetas privadas o protegidas requiere sudo.

Las tarjetas Brain guardan un abstract en texto sin cifrar (buscable dentro de los permisos de la bóveda, no un secreto protegido) y enlaces tipados { vault?, card, role?, note? } que pueden cruzar bóvedas. Entrecomille todo el valor de --link cuando contenga | o espacios para que el shell no lo interprete como una canalización. summary.type es brain con link_count. El listado/grafo/lectura resuelve títulos y tipos de enlaces cuando está permitido y marca los destinos ausentes o no autorizados como broken (sin eliminación en cascada). La búsqueda indexa el título, el resumen, los roles/notas de enlaces y los resúmenes públicos de destinos en la misma bóveda, nunca secretos. Los enlaces Brain de la misma bóveda también aparecen en card graph.

Las tarjetas de persona (summary.type = persona) guardan un núcleo de identidad entre productos con recursos de archivo enlazados, una timezone IANA para razonar sobre días/períodos locales (隔日 / 早课晚课), dominio del mundo (place / pose / look / things genéricos con atributos JSON libres / libro de registros / tiempo meteorológico / dados / ruleta / horario) y eventos de comportamiento de solo anexado marcados en UTC y hora local. Consulte docs/persona.md. Importe con memories persona import VAULT_ID ./xiaoya-persona --timezone Asia/Shanghai; actualice el estado del mundo con memories persona world-set.

Las tarjetas de flujo de trabajo (summary.type = workflow) mantienen pasos ordenados en la revisión de la tarjeta, cada uno pending, active, done o skipped, además de un estado general; memories card workflow VAULT --title Release --step "Write notes" --step Ship crea una, memories card workflow-update VAULT ASSET --advance avanza un paso y memories card list --type workflow las lista.

Una plantilla de lista de comprobación se crea con memories card workflow VAULT --template --assignee NAME --summary OVERVIEW --goal GOAL (summary.type sigue siendo workflow, el campo de perfil template es true), se lista con memories card list --type workflow --template y se copia en un flujo de trabajo de tarea con memories card workflow VAULT --template TEMPLATE, que puede enlazar otra tarjeta de flujo de trabajo con --workflow WORKFLOW y archivar una memoria con --archive MEMORY.

Los enlaces dirigidos ordinarios (card link) hacen referencia a tarjetas de la misma bóveda. Los grafos omiten los nodos eliminados, en conflicto y no autorizados y sus aristas incidentes. Las referencias permanecen en el historial cifrado. La recuperación conserva los IDs de los recursos no ambiguos para que las relaciones y las referencias de credenciales sigan funcionando en la bóveda independiente recuperada; las referencias a recursos en conflicto pueden necesitar reparación. La aplicación móvil muestra enlaces salientes, enlaces entrantes y un grafo con desplazamiento/zoom (hasta 24 nodos en el lienzo, con selección del grafo completo y listas de relaciones).

Las tarjetas protegidas guardan metadatos y una credencial separada en una sola transacción:

Los inicios de sesión web normalmente se importan en lote en lugar de introducirlos uno a uno; consulte Importar y exportar inicios de sesión web.

memories sudo
memories card account VAULT_ID --title "Example mail" --email user@example.test --smtp smtp.example.test
memories card env VAULT_ID ./app.env --title "Application config"
memories card token VAULT_ID --title "API session" --host api.example.test
memories card token VAULT_ID --title "Browser session" --host app.example.test --cookie
memories card request VAULT_ID TOKEN_CARD_ID https://api.example.test/session
memories card otp VAULT_ID --title "Example OTP" --issuer Example --account user@example.test
memories card otp VAULT_ID --title "Example HOTP" --issuer Example --account user@example.test --hotp --counter 0
memories card otp-import VAULT_ID --title "Imported OTP" --alias "Work 2FA" --notes "laptop" --category otp 'otpauth://totp/Example:user@example.test?secret=GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ&issuer=Example'
memories card otp-import VAULT_ID --image ./ga-export.png --title "GA import" --category otp
memories card otp-code VAULT_ID OTP_CARD_ID

Los títulos OTP pueden conservar la forma issuer / account de la importación mientras --alias y --notes guardan por separado un nombre para mostrar y una observación; --category los agrupa en card list.

Las contraseñas, tokens, cookies y semillas OTP usan entrada oculta del terminal, nunca argumentos de comandos. Introduzca un JWT sin procesar para el modo bearer, o name=value; other=value para el modo cookie. El SMTP de cuentas usa por defecto el puerto SSL 465; esto registra la configuración y no envía correo. Añada --id CARD_ID para sustituir los metadatos y el secreto de una tarjeta protegida; se conservan el ID de credencial y los enlaces de tarjeta. Los IDs de credenciales son referencias, no valores secretos. Las escrituras genéricas de tarjetas no pueden sustituir referencias protegidas.

El importador dotenv enmascara todos los valores, incluidos los vacíos/no secretos, y nunca indexa valores ni comentarios. Acepta un KEY=value por línea, export opcional, líneas vacías y comentarios. Se rechazan claves duplicadas y valores entrecomillados de varias líneas. No expande variables ni ejecuta el archivo. El archivo de origen original permanece donde estaba; la importación no cambia sus permisos ni lo borra. Los títulos/notas de tarjetas de texto libre no son un sistema automático de detección de secretos.

El adaptador HTTPS inyecta Authorization: Bearer ... o Cookie: ... en el cliente. Requiere sudo, el host aprobado exacto, el puerto HTTPS 443 y GET/POST. Se desactivan las redirecciones y los proxies de entorno; se devuelve únicamente el estado y se suprimen los cuerpos/cabeceras de respuesta para evitar la salida de secretos reflejados. Es un adaptador de solicitudes autorizadas, no un proxy general de reenvío ni un almacén de cookies de navegador. No están implementados la caducidad de cookies, la renovación de JWT ni el inicio de sesión automático.

TOTP admite SHA-1/SHA-256/SHA-512 (--algorithm), 6/8 dígitos (--digits) y períodos de 30/60 segundos (--period). HOTP usa los mismos algoritmos y tamaños de dígitos con --hotp y un --counter inicial (que avanza en cada otp-code). Importe URI Google Key con otp-import (otpauth://totp/... o otpauth://hotp/...), URI de migración de Google Authenticator (otpauth-migration://offline?data=...) o una imagen QR mediante --image (decodificada con rqrr en Rust puro). El tipo TOTP/HOTP se toma de la URI o del registro de migración. Cuando se omite ese tipo, un counter selecciona HOTP y todas las demás cuentas son TOTP. Las cargas de migración pueden crear varias tarjetas; --title es el título de una sola tarjeta o un prefijo de lote. otp-code devuelve el código de corta duración después de sudo y audita la generación sin guardar el código en los registros de auditoría; las respuestas HOTP incluyen el siguiente contador. La búsqueda y MCP nunca generan códigos ni devuelven semillas. La aplicación móvil oculta los códigos caducados y cierra el diálogo al bloquear/pasar a segundo plano. Mantenga el reloj del dispositivo exacto para TOTP. La aplicación móvil no escanea códigos QR OTP con la cámara; use --image de la CLI o pegue una URI otpauth:// / de migración. El emparejamiento hospedado de dispositivos tiene un flujo de cámara separado; consulte center.

La aplicación móvil tiene las acciones Tarjeta protegida, Importar .env e Importar inicios de sesión (CSV). La información básica de cuentas/credenciales aparece directamente en los resultados de búsqueda y detalles de tarjetas. Las tarjetas de token y OTP proporcionan las acciones de menú Solicitud autorizada y Generar OTP. La edición genérica de tarjetas conserva los metadatos protegidos; actualmente, la sustitución de secretos usa la CLI.

Importar y exportar inicios de sesión web

Los inicios de sesión web se guardan en tarjetas protegidas login y se mueven en lote. La importación y la exportación requieren memories sudo y un rol con escritura.

memories sudo
# Browser CSV (Chrome/Edge/Brave or Firefox about:logins); the header is detected.
memories login import VAULT_ID --from chrome passwords.csv
memories login import VAULT_ID --from firefox firefox-logins.csv --with-notes
# Read a Firefox profile directly (modern key4.db; prompts for any primary password).
memories login import VAULT_ID --from firefox-profile "/path/to/Profiles/xxxx.default"
# Windows Credential Manager generic credentials (Windows only).
memories login import VAULT_ID --from windows --filter github
memories login import VAULT_ID --from windows --all
# A previous encrypted export.
memories login import VAULT_ID --from memories logins.mlx

# Export: portable encrypted file (recommended) or a browser-compatible CSV.
memories login export VAULT_ID --format encrypted logins.mlx
memories login export VAULT_ID --format csv logins.csv

Un inicio de sesión con el mismo host de sitio y nombre de usuario que una tarjeta existente se omite cuando coincide la contraseña y se notifica como conflicto cuando difiere; --update sobrescribe en su lugar. Las filas CSV incorrectas se omiten y se notifican por número de línea; una importación está limitada a 2000 inicios de sesión. La columna note del navegador se importa únicamente con --with-notes, porque las notas se indexan como texto ordinario. La lectura directa de Firefox maneja el formato moderno de claves (Firefox 58+); para perfiles antiguos, exporte un CSV desde about:logins. Leer las contraseñas guardadas de un navegador requiere que ese navegador esté cerrado en algunas plataformas y nunca modifica el almacén del navegador.

La exportación cifrada usa una contraseña independiente y se importa en cualquier bóveda. La exportación CSV es texto sin cifrar para mover inicios de sesión de vuelta a un navegador u otro gestor de contraseñas: es exclusiva de la CLI local, imprime una advertencia, escribe un archivo exclusivo del propietario que no debe existir previamente, neutraliza la inyección de fórmulas de hojas de cálculo y debe eliminarse después de usarlo. Las bóvedas exclusivas de un dispositivo no pueden exportarse.

Configuración exclusiva del dispositivo

memories local-python
memories local-python --program /path/to/python
memories vault list
memories card search LOCAL_VAULT_ID Python

Esto ejecuta el intérprete Python seleccionado en modo aislado para registrar su versión y directorio del ejecutable. No recopila variables de entorno. Cada llamada registra una nueva observación en la bóveda cifrada Este dispositivo con local_only: true. Esa bóveda completa se excluye de los paquetes de autorización de dispositivos y de las copias de seguridad exportadas; se rechazan las invitaciones de miembros, la exportación/importación de sincronización y la sincronización de políticas. Sigue siendo buscable en este dispositivo y persiste tras bloqueo/reinicio, pero la recuperación de copias de seguridad exportadas deliberadamente no la restaura. Cree tarjetas de conocimiento en esta bóveda para registrar otra configuración local. El emparejamiento de dispositivos sigue requiriendo un destino sin bóvedas existentes; empareje primero antes de crear sus observaciones de configuración local.

Actualice todos los clientes participantes antes de intercambiar tarjetas: los clientes antiguos no entienden el nuevo tipo card ni los metadatos protegidos.

Móvil

En el primer inicio, elija Standalone, Center o SaaS. Standalone usa la biblioteca local cifrada. Center solicita la URL de su servidor hospedado y el token de miembro; SaaS usa https://memories.ivjn.us y solicita un token de miembro. Los modos hospedados no requieren crear ni desbloquear una biblioteca local. Use Cambiar modo en la barra de herramientas principal para cambiar posteriormente; los datos existentes permanecen en su almacén original. Consulte la guía móvil para conocer los pasos de conexión, funciones disponibles, autorización, edición y resolución de problemas, o la guía de uso en chino.

Compilar y validar el cliente móvil

Use Flutter 3.44.2 (la versión de CI), JDK 17+, Android SDK/NDK y cargo install cargo-ndk --locked. Esta copia de trabajo se compiló con NDK 28.2.13676358 y las plataformas SDK 35, 36 y 37.0 (el SDK de Flutter y los plugins seleccionan sus plataformas de compilación). Acepte las licencias de Android SDK antes de compilar. Haga que flutter esté disponible en PATH e instale los destinos Rust aarch64-linux-android y x86_64-linux-android con rustup target add.

.\scripts\build-android.ps1 -Apk

Esto compila bibliotecas nativas ARM64/x86_64 y un APK de depuración en mobile/build/app/outputs/flutter-apk/app-debug.apk. No se incluyen credenciales de firma de release. En macOS con Xcode, use bash scripts/build-ios.sh y después firme y ejecute la aplicación con su propio equipo de desarrollo. Las bibliotecas estáticas de iOS se enlazan forzosamente para que los símbolos Dart FFI sigan disponibles.

Después de compilar las bibliotecas nativas, ejecute la prueba de humo real de la ABI móvil en un dispositivo o emulador conectado desde mobile:

flutter test integration_test/native_smoke_test.dart -d DEVICE_ID

Esta prueba usa una biblioteca temporal y comprueba el almacenamiento cifrado, la autorización, la denegación de lectura de credenciales, la verificación de auditoría y el bloqueo/desbloqueo mediante Rust FFI. Recompile después el APK normal porque las pruebas de integración de Flutter sustituyen el punto de entrada del APK de depuración por su ejecutor de pruebas.

En modo Standalone, el cliente móvil usa el mismo servicio Rust mediante C FFI, búsqueda local de texto completo, selectores de archivos, archivos de aprobación de dispositivos/miembros, transferencias de relay en línea y vistas de historial y auditoría. Un factor local protegido por Keychain/Keystore complementa la contraseña. Pasar a segundo plano borra la autorización y cierra los diálogos de contenido; Android bloquea las capturas de pantalla e iOS cubre la instantánea del selector de aplicaciones. La sincronización en segundo plano no está habilitada en esta versión.

Center y SaaS usan el cliente hospedado Rust mediante FFI para aprobaciones de solicitudes, navegación de conocimiento, búsqueda del lado del servidor, detalles, edición, eliminación y emparejamiento de dispositivos. Las acciones siguen el alcance del token; las tarjetas estructuradas/selladas requieren sus editores especializados. Pasar a segundo plano cierra la sesión hospedada; use Reconectar sesión guardada o introduzca un token de nuevo al regresar. Consulte la comparación de modos antes de elegir un flujo de trabajo.

Repositorio

Consulte docs/architecture.md y docs/validation.md para obtener detalles de implementación y verificación. El diseño de almacenamiento y sincronización OneDrive/Google Drive está documentado en docs/cloud-storage-design.md. Están implementadas la autorización de la CLI y cloud sync; las transferencias de proveedores se han probado con fixtures locales, sin cuentas reales. Los controles de inicio de sesión/sincronización móviles usan AppAuth y el worker Rust compartido; el consentimiento real y la verificación de plataformas siguen siendo requisitos para publicar.