MemoriesArquitectura y protocolo v1
Almacenamiento
El esquema de la base de datos consta de header, state y checkpoints. Salvo los metadatos de formato, la sal y los números de secuencia de las filas, los valores son texto cifrado autenticado. Los registros transaccionales también contienen texto cifrado. No existe un índice FTS persistente en texto sin cifrar. La memoria ordinaria autorizada se divide en fragmentos superpuestos seguros para Unicode y se tokeniza con Jieba antes de entrar en un índice SQLite FTS5 en memoria. La caché se identifica por el estado de política/revisión/cuarentena de la bóveda y se reutiliza entre consultas; las ediciones, la sincronización y los cambios de política la invalidan, y el bloqueo la vacía. El almacenamiento temporal de SQLite se mantiene deliberadamente solo en memoria. Los vectores se normalizan y se almacenan en caché únicamente en memoria; ni los índices en texto sin cifrar ni las representaciones vectoriales entran en las cargas de copia de seguridad o sincronización.
La clave derivada de la contraseña envuelve una clave maestra aleatoria; esta cifra el estado y los puntos de control locales. Cada época de permisos tiene una clave de bóveda, y cada revisión tiene una clave de datos aleatoria envuelta bajo la clave de su época. El contenido se serializa y se divide en fragmentos de 256 KiB autenticados individualmente, cuya posición y cantidad total quedan vinculadas a los datos asociados. La firma de la revisión cubre su ID de activo, sus padres, la cabecera de política, el indicador de eliminación, el texto cifrado y el certificado del dispositivo.
Las modificaciones se preparan sobre un estado clonado y se confirman junto con el estado cifrado y el punto de control en una sola transacción SQLite con synchronous=FULL. Las intenciones de lectura y ejecución se confirman antes de la entrega. Por tanto, un fallo de disco impide la entrega; una caída después de confirmar la intención puede dejar un resultado desconocido.
Un bloqueo exclusivo del sistema operativo permite un único escritor local cooperante. La inicialización crea una base de datos completa en el mismo directorio, la cierra y sincroniza, y después la publica sin sobrescribir un destino existente. Una preparación interrumpida no impide reintentar. Cada dispositivo necesita su propio almacén local; copiar archivos SQLite activos mediante un cliente de sincronización en la nube no proporciona seguridad transaccional entre dispositivos.
Identidades y transporte
Las claves Ed25519 del usuario certifican las claves de firma Ed25519 y las claves de intercambio X25519 de los dispositivos. Los certificados por sí solos no bastan: cada política de bóveda autoriza deliberadamente los dispositivos. Las claves de dispositivo son independientes, incluso entre dispositivos del mismo usuario. La autoridad inicial de firma del usuario se entrega a los dispositivos personales aprobados dentro de un paquete autenticado y cifrado para el destinatario; esa autoridad no puede eludir la lista de dispositivos permitidos de una bóveda después de revocar un dispositivo.
Un sobre contiene una versión de formato, la clave del dispositivo emisor, la clave de intercambio del destinatario, una clave pública X25519 efímera, una carga AEAD y una firma Ed25519. HKDF deriva la clave de transporte. Se autentican la identidad del destinatario y la clave efímera. El dispositivo que se incorpora utiliza una solicitud firmada con caducidad y fija deliberadamente la clave pública del dispositivo aprobador; las solicitudes se consumen solo tras una confirmación correcta.
La primera versión utiliza cadenas y archivos de solicitud/aprobación en lugar de escanear QR con la cámara. Las huellas son resúmenes SHA-256 completos; los valores abreviados de las listas nunca deben utilizarse como única comprobación de aprobación.
Políticas y combinación
Las políticas de bóveda son historiales lineales firmados que contienen miembros, roles, la lista de dispositivos permitidos, un conjunto de dispositivos revocados que crece monótonamente y la época. Las comprobaciones de roles utilizan la política anterior. Los usuarios ordinarios pueden autorizar otro dispositivo para su propia identidad sin cambiar los miembros. Un Admin puede cambiar la pertenencia de Admin, Editor y Reader y autorizar el dispositivo de un miembro. Un Admin no puede añadir, eliminar ni modificar un Owner, revocar dispositivos ni transferir la propiedad. Los Owners sí pueden. La transferencia de propiedad mantiene exactamente un Owner.
Los historiales de activos forman un DAG direccionado por contenido compartido por todos los tipos editables (memoria, tarjeta —incluidos knowledge, brain, persona y los metadatos de tarjetas protegidas—, archivo y credencial). Cada guardado añade una revisión firmada; no existe un almacén de historial separado exclusivo de la wiki ni una poda automática. history enumera revisiones con autor y resumen; diff devuelve una proyección textual unificada (título, metadatos estructurados, cuerpo) entre dos revisiones o respecto al HEAD actual. Las diferencias de archivos omiten las cargas binarias; los cuerpos secretos de las credenciales siguen sin estar disponibles mediante lectura/diff. Varias revisiones no consumidas de un activo son conflictos; una revisión de resolución nombra todos los padres visibles. Un marcador de eliminación quita el activo de las vistas actuales sin borrar su historial.
La sincronización valida los historiales completos de políticas, revisiones y auditoría antes de combinarlos en un estado candidato. Las escrituras desconocidas de épocas sustituidas se ponen en cuarentena. Las escrituras locales sin conexión ausentes de una instantánea entrante de política más reciente también se ponen en cuarentena. La cuarentena solo puede revisarse/reaplicarse localmente; no puede eliminarla un campo entrante no confiable.
Las bifurcaciones de permisos requieren una firma del propietario sobre la cabecera elegida y toda la cadena de políticas descartada. El firmante debe ser propietario en ambas ramas. Las políticas descartadas siguen siendo verificables para revisiones históricas/en cuarentena. Una resolución correcta avanza la política seleccionada y rota su clave. Las resoluciones competidoras o incompatibles deniegan el acceso por defecto.
API local
service::Request es la interfaz compartida de operaciones tipadas, serializada con el discriminador op en snake case. Se rechazan los campos desconocidos del nivel superior. El IPC local utiliza tramas JSON con prefijo de longitud de 32 bits big-endian (envoltorio Wire de versión 1). La escucha opcional HTTP/WebSocket y el RPC de retransmisión utilizan el mismo enmarcado JSON binario de WebSocket (AuthFrame y después Wire) tras autenticar el token. Las capacidades MCP se comprueban por separado antes del despacho. RunBound se despacha como RemoteExec: run_bound_prepare autoriza y descifra bajo el bloqueo del servicio, el hilo IPC ejecuta el programa sin bloqueo y run_bound_finish audita el resultado. Los enlaces de ejecución residen en State.run_bindings, local al dispositivo, no en una bóveda.
Los transportes de red pueden llevar Requests enmarcadas y autenticadas por token. Los tokens proceden únicamente de opciones/entorno (nunca de TOML), se comparan en tiempo constante y se borran cuando se bloquea el almacén. Los llamantes remotos utilizan espacios de nombres estables de elevación (ws:remote / relay:remote) que no heredan la elevación local cli:{pid}; desbloquear y usar sudo mediante conexión remota eleva ese espacio de nombres para conservar la elevación entre conexiones CLI de una sola operación. Los anfitriones HTTP/retransmisión de escritorio despachan toda la superficie handle_client (con los mismos controles de elevación que el IPC local). La FFI móvil y Share mantienen la lista de exclusión de la plataforma y no introducen funciones exclusivas del escritorio en el teléfono. La escucha HTTP usa loopback por defecto; los enlaces fuera de loopback requieren --allow-non-loopback y una advertencia. HTTP/WS sin cifrar no necesita certificados; --tls-cert / --tls-key habilitan HTTPS/WSS. El RPC de retransmisión usa WSS fuera del ámbito de confianza con un ID de sala de alta entropía y un token; la sincronización de bóvedas conserva /v1/channel. La WebUI tiene una proyección de estado de solo lectura y un editor restringido de tarjetas ordinarias, y no es un transporte de Request. Consulte daemon remoto y SECURITY.md.
Los Centers de autorización opcionales ([[centers]] en la configuración) prohíben la inicialización autónoma local y la emisión local de concesiones MCP; la inscripción y las concesiones se distribuyen como tickets firmados por Center con ámbitos deliberados (allow_all / read / write / read_write / read_write_delete). Consulte Center.
El modo alojado opcional de Center (--data DIR) posee un Store cifrado separado en formato de daemon bajo DIR/store/, abierto con una contraseña de servidor que conserva el operador. Su RPC HTTP de contenido utiliza en Service un despachador cerrado de concesiones por bóveda; la elevación local a cada operación cubre contenido protegido/privado y adjuntos sin cambiar la autorización MCP del daemon. Es cifrado del lado del servidor, no cifrado de extremo a extremo del cliente. Rutas HTTP administrativas separadas gestionan el bloqueo/desbloqueo alojado y las concesiones duraderas con nombre en DIR/members.json, accesible solo por el propietario. Los tickets firmados de desbloqueo solo autorizan el desbloqueo por contraseña del dispositivo local; las claves de dispositivo nunca llegan a un Center que solo emite tickets. Una única entrada [[centers]] con mode = "saas" hace que el RPC de contenido del daemon utilice ese backend alojado y su token bearer del entorno, sin una ruta paralela de contenido local ni elevación de capacidades MCP. Los controles de dispositivos/administración no forman parte de la superficie de contenido de concesiones. Consulte bóveda alojada de Center para conocer los límites y la migración.
La ABI móvil se declara en crates/ffi/memories.h. Los identificadores de instancia son IDs numéricos del registro, no punteros Rust sin procesar. Cada cadena devuelta debe liberarse una vez con memories_free. Un JSON no válido produce un error genérico sin repetir la entrada. memories_lock_all avanza una generación global de bloqueo al pasar a segundo plano y suprime las respuestas tardías en curso. El registro almacena bloqueos de servicio por instancia con recuento de referencias; el trabajo de red no mantiene el bloqueo del registro ni del escritor. Una instancia ocupada aplica un bloqueo pendiente antes de su siguiente solicitud. La versión móvil excluye la ejecución de procesos y la creación de concesiones MCP.
El selector de modo de Flutter (mobile/lib/app_mode.dart) dirige Standalone a la biblioteca local y Center/SaaS a HostedCenterPage. Aquí Center significa un servidor propio con almacenamiento alojado; SaaS selecciona el endpoint fijo https://memories.ivjn.us. Ambos utilizan las mismas operaciones FFI Rust hosted_* y HostedClient; la selección no modifica el TOML del daemon, inscribe un dispositivo gestionado por tickets ni mueve datos entre almacenes.
El modo seleccionado es una preferencia no secreta. Center y SaaS almacenan cada uno un perfil URL/token en el almacenamiento seguro de la plataforma. Cambiar de modo bloquea el servicio local, detiene la compartición y desecha la página/sesión alojada. Pasar a segundo plano borra el contenido alojado e invalida las respuestas tardías; la reconexión al volver es explícita. Consulte configuración móvil para las claves de perfil y el comportamiento de actualización, y la guía móvil para los pasos del usuario.
Bandeja de escritorio y proyección de estado
Request::DesktopStatus devuelve una proyección tipada del estado de inicialización/bloqueo, las cantidades de bibliotecas y conexiones, los tipos de proveedores configurados y las cantidades de las colas de sincronización. Se ejecuta antes del despacho de operaciones desbloqueadas y no clona ni confirma el estado cifrado, modifica los temporizadores de inactividad/elevación ni expone identificadores, resúmenes de cuentas, contenidos o credenciales. Las respuestas bloqueadas no tienen detalles. La lista MCP de permisos existente deniega esta solicitud.
La biblioteca CLI aloja el panel local y la bandeja de Windows/macOS. Tanto memories tray como el lanzador independiente memories-tray utilizan un bucle de eventos nativo en el hilo principal. El servidor HTTP y el trabajador acotado de sondeo de estado se ejecutan por separado para que un daemon ocupado no bloquee la bandeja ni el navegador. El sondeo invoca el CLI hermano mediante el IPC normal autenticado por el sistema operativo, con un plazo y limpieza del proceso hijo. La superficie HTTP sirve recursos integrados, la proyección fija de estado y una lista deliberada de permisos de edición de tarjetas ordinarias/tipos. No puede desbloquear, elevar, revelar secretos ni despachar solicitudes de servicio arbitrarias. Consulte SECURITY.md para su límite de token y origen del navegador, y uso del escritorio.
Recuperación de información y orquestación de modelos
search::Cache posee como máximo dos índices de bóveda, cada uno limitado a 10,000 fragmentos, 16 MiB de texto/metadatos de origen y 32 MiB de vectores. Excluye contenido privado, credenciales, archivos y contenido eliminado, en cuarentena o en conflicto antes de indexar. BM25 pondera título/cuerpo/metadatos como 5/1/2. La búsqueda vectorial usa similitud coseno; la búsqueda híbrida combina ambas clasificaciones mediante fusión por rango recíproco. La reclasificación predeterminada refuerza la cobertura de la consulta y las coincidencias de frases exactas dentro de un conjunto acotado de candidatos. Un endpoint de modelo configurado puede realizar reclasificación aprendida.
Retrieve, RagIndex, RagStatus y RagAsk mantienen la autorización de bóveda y los ámbitos de concesiones MCP. El IPC ejecuta el trabajo de modelos fuera del mutex del servicio y vuelve a comprobar la generación de desbloqueo, la validez de la concesión, el acceso y la marca de revisión de origen antes/después del trabajo externo y antes de entregar. Las intenciones firmadas preceden a la inferencia/exportación; se auditan el éxito/fallo y los IDs de fuentes entregadas sin prompts ni claves. Las referencias de activos/revisiones de origen usan la proyección compartida de IDs cortos; los hashes de fragmentos y las etiquetas de cita [S1] no son IDs de activos.
rag::Runtime carga de forma diferida la inferencia ONNX nativa y los recursos fijados de EmbeddingGemma Q4, o llama a una URL configurada de representaciones vectoriales de Gemini/compatible. También admite URLs configuradas de generación y reclasificación, claves API referenciadas desde el entorno, proxies y reintentos. Los archivos de modelos nativos son datos públicos de modelos; los registros cifrados de los usuarios nunca se convierten en pesos de modelos. El texto recuperado es información no confiable en los prompts de generación, y los IDs de citas devueltos se validan frente a las fuentes seleccionadas. Esto valida las referencias, no la corrección factual del texto generado por el modelo.
La FFI móvil recibe la búsqueda léxica mejorada y admite retrieve con BM25. Las operaciones basadas en modelos utilizan actualmente el daemon de escritorio configurado; esta versión no añade a Flutter una interfaz de configuración o inferencia de modelos.
Trabajos criptográficos de escritorio
jobs::Job describe herramientas, archivos/árboles de entrada fijados, enlaces de credenciales, pasos ordenados, limpieza y una nueva ruta de salida. Las recetas crypto del CLI construyen este plan para S/MIME/OpenPGP y la firma Android/iOS. La aprobación se comprueba antes de resolver los IDs cortos, de modo que su resumen vincula exactamente las referencias mostradas al llamante. El servicio comprueba la elevación local y el acceso a la bóveda, resuelve solo activos de credenciales, confirma una intención de ejecución e invoca después el ejecutor compartido del núcleo.
El ejecutor vuelve a comprobar las herramientas, copia y verifica las entradas, materializa las credenciales en un espacio de trabajo privado, ejecuta comandos sin shell, suprime sus salidas y publica únicamente un artefacto correcto. La expansión de marcadores sustituye solo rutas y no interpreta recursivamente su contenido. La lista de permisos MCP y la FFI móvil deniegan trabajos de procesos. La semántica existente de run no cambia.
Habilidades de clientes de IA
memories inject es una operación de instalación exclusiva del CLI. skills.rs integra en el ejecutable el archivo versionado crates/cli/skills/memories/SKILL.md y lo instala en los directorios documentados de descubrimiento de Codex, OpenCode o Claude Code. Se ejecuta antes de crear el directorio de datos y nunca abre el almacén ni llama al daemon. Los ámbitos de usuario y proyecto comparten el mismo texto de instrucciones; no se interpolan rutas de almacenes, IDs de bóvedas, tokens de concesión ni material secreto.
El instalador comprueba previamente todos los destinos, conserva los archivos idénticos, requiere --force para contenidos diferentes, rechaza archivos/directorios de habilidades enlazados y publica cada archivo mediante un archivo temporal sincronizado en su directorio de destino. Los archivos nuevos se publican sin sobrescribir otro creado simultáneamente. Esto proporciona atomicidad por archivo, no una transacción entre clientes. Se conservan los recursos hermanos y la configuración de clientes existentes. La habilidad dirige la búsqueda ordinaria, la recuperación con citas, las respuestas configuradas y las escrituras a través de las interfaces MCP o CLI existentes; no añade capacidades de autorización.
Autorización en la nube
El CLI de escritorio realiza OAuth en el navegador con PKCE, una devolución de llamada loopback y endpoints fijos de proveedores. CloudBegin crea bajo sudo un ticket con caducidad vinculado al llamante/proveedor/cliente. Las solicitudes de red se ejecutan fuera del daemon; CloudComplete comprueba el ticket y la autorización actual antes de confirmar. El bloqueo, el cierre de sesión y el reinicio invalidan los tickets pendientes para evitar que los resultados tardíos restauren la sesión.
State.cloud_accounts almacena tokens cifrados en el dispositivo local. El estado devuelve solo metadatos de cuentas; las copias de seguridad, el emparejamiento, la sincronización de bóvedas y MCP excluyen los tokens. Iniciar sesión no establece pertenencia a una bóveda.
Sincronización de objetos en la nube
State.cloud_sync mantiene recibos duraderos de salida/entrada dentro del mismo bloque de estado cifrado. CloudSyncEnqueue escribe los bytes exactos del sobre serializado y un descriptor firmado antes de cualquier E/S de transporte. Los IDs de objetos son SHA-256 de esos bytes; los reintentos los reutilizan. CloudSyncWork devuelve texto cifrado y cursores de listado sin tokens OAuth. sync::execute realiza operaciones put/get/list acotadas sin el mutex del servicio. CloudSyncAck comprueba una generación de sesión local al proceso y después confirma conjuntamente los indicadores de carga, los IDs descubiertos, los bytes descargados y las combinaciones de bóvedas. Los descriptores que llegan antes que sus objetos quedan pendientes. Bloquear, desbloquear y cerrar sesión incrementan la sesión para que las confirmaciones tardías no puedan importar. memories cloud sync pide al daemon actualizar tokens, cargar y descargar mediante carpetas de aplicación de OneDrive o Google Drive; ese HTTP se ejecuta fuera del bloqueo del escritor. Los tokens nunca se devuelven mediante IPC. Las pruebas también usan MemoryTransport y entornos de prueba Graph/Drive en loopback. Las cargas de colas completadas se compactan en recibos hash y marcas de publicación por proveedor/destinatario. Los recibos permanecen locales y no eliminan el historial de la nube. Los objetos ausentes se reintentan con un retraso exponencial persistido; la capacidad pendiente aplica contrapresión al listado. Los trabajadores de proveedores serializan por cuenta y rechazan resultados de actualización/importación de una sesión invalidada. El despacho IPC usa como máximo 16 conexiones simultáneas.
Consulte el diseño de sincronización y la guía de autorización.
Sesiones remotas
El daemon de escritorio posee las conexiones SSH, FTP, TCP, MySQL, Redis y PostgreSQL. RemoteOpen valida la lista de hosts permitidos de la credencial, registra una intención de conexión y conecta después fuera del bloqueo del escritor. SSH se autentica con una credencial de contraseña o una clave privada OpenSSH importada, opcionalmente junto a una credencial de certificado OpenSSH. CredentialGenerate crea claves SSH y certificados TLS bajo sudo; la clave privada se almacena como credencial y nunca se devuelve. CredentialPublic deriva claves públicas SSH o certificados PEM de ese material almacenado. Las sesiones de base de datos habilitan TLS por defecto y pueden añadir una credencial CA PEM opcional (tls_ca) al almacén de confianza del cliente. Se exige verificar el nombre del host; no se implementa la fijación de certificados. Cada instrucción se propone como un ticket cuya huella cubre la sesión, la secuencia y la instrucción canónica. RemoteApprove es de un solo uso y está vinculado al llamante elevado; RemoteExec ejecuta únicamente ese ticket en la sesión existente. Bloquear, vencer la inactividad y cerrar sesión eliminan las conexiones activas y los tickets pendientes. Las operaciones de archivos utilizan FTP; las sesiones SSH y de base de datos aceptan exec/query. ProxyStart enlaza un listener loopback tras las mismas comprobaciones de credenciales y listas de hosts permitidos que RemoteOpen. Los clientes locales conectan sin secretos; el daemon conserva la autenticación SSH o de base de datos del destino. proxy.start registra la intención de conexión antes del enlace; proxy.stop registra la intención de parada. El socket enlazado se transfiere directamente a Tokio sin un intervalo de cierre/reenlace. PostgreSQL SSLRequest y MySQL SSLRequest preceden a la actualización TLS; Redis utiliza TLS directo. PostgreSQL SCRAM comprueba tanto el nonce como la firma del servidor. MySQL admite autenticación nativa y caching-SHA-256, incluidos cambios de plugin; el intercambio completo de contraseñas requiere TLS. Los protocolos iniciales de bases de datos tienen un plazo de 30 segundos, límites de paquetes de 64 KiB y un máximo de 16 clientes por listener. El salto local de base de datos es texto sin cifrar y los campos de inicio de sesión/base de datos no sustituyen la identidad configurada del destino. Los clientes locales autorizan instrucciones remotas sin restricciones dentro de los permisos de esa cuenta. Loopback no proporciona autenticación por usuario. El bloqueo, la caducidad por inactividad de la bóveda, la parada deliberada y la destrucción del servicio cancelan los listeners y las sesiones activas. Los proxies tienen una duración máxima de 30 minutos; el tráfico no prolonga el desbloqueo de la bóveda. MCP no puede gestionar proxies. El servicio posee cada trabajador proxy y espera su terminación al parar/bloquear, de modo que una respuesta correcta no pueda coincidir con una conexión que siga reenviando instrucciones.
Ejecución de archivos de configuración
memories file exec combina la solicitud autorizada Read existente con la materialización local de archivos y la supervisión de procesos del CLI. No introduce una nueva solicitud de servicio, tipo de archivo, criptografía ni permiso de ejecución móvil/MCP. El daemon audita la entrega del archivo mediante la ruta de lectura existente, y después el CLI ejecuta el proceso hijo en primer plano sin ocupar el bloqueo del servicio. El CLI posee la instantánea temporal en texto sin cifrar hasta que termina el hijo directo; los cambios posteriores o el bloqueo de la bóveda no modifican/revocan esa instantánea ya entregada.
Recuperación
Las copias de seguridad contienen el estado local firmado y el material secreto de recuperación bajo un sobre Argon2id/AEAD independiente. La recuperación genera nuevas claves de dispositivo y crea IDs de bóvedas independientes, conservando el contenido actual y las cabeceras en conflicto. Los historiales originales firmados se conservan en un archivo cifrado de solo lectura. La recuperación no afirma que una pertenencia compartida histórica siga vigente. Se excluyen las bóvedas exclusivas de dispositivo, las autorizaciones en la nube y los recibos de salida/entrada de la nube; cada dispositivo recuperado inicia sesión en los proveedores de nube por separado.
Tarjetas y proyecciones seguras
Kind::Card comparte la autorización de memoria ordinaria, con metadatos tipados almacenados dentro de revisiones cifradas. CardLink añade aristas dirigidas dentro de la misma bóveda. Los grafos proyectan únicamente nodos actuales, inequívocos y visibles y aristas con ambos extremos visibles. La búsqueda utiliza la caché FTS5 acotada en memoria descrita anteriormente, que cubre cuerpos ordinarios, etiquetas/fuentes y metadatos permitidos de tarjetas protegidas. Los cuerpos de credenciales nunca entran en este índice. Búsqueda/listado/grafo exponen una proyección segura summary; las lecturas de tarjetas conservan la referencia opaca de credencial, pero nunca resuelven su valor.
protected_card valida una entrada account/env/token/TOTP/HOTP (incluida la importación de URI otpauth), escribe una credencial y su tarjeta en un estado candidato y confirma ambas conjuntamente. El put genérico no puede adjuntar ni sustituir referencias protegidas. Las operaciones secretas resuelven las revisiones actuales de credenciales y verifican su tipo. otp_code implementa RFC 6238 (TOTP) y RFC 4226 (HOTP), avanza el contador HOTP en la misma confirmación y registra la intención de entrega antes de devolver un código. La construcción de cabeceras HTTP marca los valores bearer/cookie como sensibles, con redirecciones deshabilitadas y respuestas suprimidas.
El contenido de memorias y tarjetas también puede llevar un mapa secrets de una etiqueta estable a un ID canónico de activo de credencial. protect_secret sustituye coincidencias exactas del cuerpo por {{secret:LABEL}} y crea la credencial en la misma transacción. El put genérico exige que las asignaciones existentes permanezcan sin cambios y no puede inventarlas ni redirigirlas. Las ediciones CLI y móviles conservan el mapa existente. El card_write de MCP omite el mapa, por lo que las actualizaciones de tarjetas con referencias secretas no superan la validación. La proyección del cliente acorta únicamente los IDs tipados de credenciales y mantiene estables los marcadores del cuerpo. La recuperación de copias de seguridad conserva IDs inequívocos de activos, por lo que las asignaciones sobreviven a la recuperación. credential_copy resuelve directamente una etiqueta, una tarjeta protegida o una credencial, requiere elevación local y confirma la intención de auditoría antes de devolver texto UTF-8 sin cifrar al cliente del portapapeles. MCP rechaza ambas operaciones nuevas. Ninguna operación genérica de lectura, búsqueda o grafo resuelve un secreto. Los cuerpos históricos firmados no cambian con la sustitución; consulte los límites de wiki y portapapeles en SECURITY.md.
El servicio devuelve {"secret":"..."} únicamente al llamante local de copia autorizado. El CLI consume esta respuesta en clipboard.rs y devuelve {"copied":true} dentro de su sobre normal de salida solo después de escribir correctamente en el portapapeles. La versión móvil utiliza el canal de portapapeles de Flutter y comprueba su generación de ciclo de vida antes de entregar. La auditoría registra credential.copy con delivery_intent, no un recibo de éxito del portapapeles del sistema operativo. Consulte la guía de uso.
State.local_vaults marca las bóvedas exclusivas de dispositivo dentro del estado local cifrado. local_config registra metadatos de versión y directorio recopilados por el cliente en una de esas bóvedas. La aprobación de dispositivos filtra esas bóvedas; se rechazan la exportación directa de miembros y la sincronización; store::backup las elimina de su instantánea exportada. Los IDs inequívocos de activos sobreviven a la recuperación en una nueva bóveda, conservando las referencias de grafos y de tarjetas a credenciales y dejando archivados los historiales originales firmados.