@dotrino/identity 0.114.1 → 0.116.0

package/vault/vendor/passmanager/transport/protocol.js

@@ -0,0 +1,83 @@
+// El protocolo entre quien pide una credencial y quien la custodia.
+//
+// Viaja por @dotrino/proxy-client (`sendByPubkey`), que es el transporte del
+// ecosistema — no se abre un socket propio ni se reimplementa nada de esto.
+//
+// El contenido lo sella el TRANSPORTE (`@dotrino/proxy-client` ≥ 0.13.0), no esto:
+// aquí solo se define qué se pide y cómo se contesta. Ojo con la suposición fácil —
+// el proxio enruta pero NO cifra, y darlo por hecho fue el agujero del §2.2.
+
+export const TYPE = 'dotrino.passmanager/1'
+export const REPLY = 'dotrino.passmanager.reply/1'
+
+/**
+ * Lo que un aparato puede pedir. `list` NO está, y esa ausencia es el diseño: si un
+ * aparato pudiera pedir la bóveda entera, el «de a una» no significaría nada.
+ *
+ * Y no lo puede una consola tampoco. Fue la tentación al diseñar `pass.dotrino.com`:
+ * darle `list` «porque es la consola» habría abierto el mismo agujero con otro nombre
+ * — bastaría con llamarse consola. Listar es de quien tiene la llave.
+ */
+export const REMOTE_OPS = ['find', 'get', 'put', 'patch', 'search', 'remove', 'sites']
+
+/**
+ * LAS OPERACIONES DEL FORMATO SELLADO (`docs/sealed-passwords.md`).
+ *
+ * Son OTROS NOMBRES, no los mismos con otro payload, y eso es a propósito: un aparato
+ * viejo que hable con una bóveda nueva recibe «operación no permitida» —un error que se
+ * ve— en vez de mandar un `find` con una URL a algo que espera huellas y quedarse mirando
+ * una respuesta vacía. Las incompatibilidades tienen que doler al instante
+ * (`CONVENCIONES-APPS.md` §14).
+ *
+ *   `pm2.recipients`  a quién hay que envolverle cada llave (sale del acta) + la pública
+ *                     de recuperación. Se pide ANTES de guardar nada.
+ *   `pm2.profile`     la llave del perfil sellada, de la que salen el índice y los resúmenes
+ *   `pm2.views`       las vistas selladas que este aparato puede abrir (sustituye a `list`,
+ *                     `search` y `sites`: la bóveda ya no puede buscar por texto)
+ *   `pm2.find`        las vistas cuyo índice casa con estas huellas de sitio
+ *   `pm2.passkey`     lo mismo para una passkey (por sitio o por credencial)
+ *   `pm2.get`         los sobres de los campos pedidos, con la envoltura de quien pregunta
+ *   `pm2.put`         guardar una entrada entera, ya cerrada y firmada
+ *   `pm2.patch`       cambiar unos campos sin leer los demás
+ *   `pm2.remove`      quitarla
+ */
+export const SEALED_OPS = [
+  'pm2.recipients', 'pm2.profile', 'pm2.views', 'pm2.find', 'pm2.passkey',
+  'pm2.get', 'pm2.put', 'pm2.patch', 'pm2.remove'
+]
+
+// `sites` entró el 2026-08-29, decidido por el dueño para que el gestor abra con los
+// dominios en vez de con un buscador vacío. NO es `list` con otro nombre —de ahí no sale
+// ni un id ni un nombre, solo el dominio, que ya va en claro (§5)—, pero sí contesta de
+// una vez lo que antes había que preguntar sitio por sitio. Queda dicho a propósito.
+
+// `search` estaba implementado en las dos puntas y NO en esta lista, así que por el
+// proxio se contestaba «operación no permitida»: traerse la cuenta de otro dominio
+// funcionaba con la bóveda de dentro y no con una conectada. Corregido el 2026-08-29.
+
+/**
+ * Administración de APARATOS: qué aparatos hay y retirar uno. No toca credenciales.
+ * Va aparte porque exige aprobación siempre — quitar un aparato es tan delicado como
+ * entregar una contraseña, y en el otro sentido.
+ */
+export const ADMIN_OPS = ['devices', 'unlink']
+
+export function isRequest (msg) {
+  return !!msg && msg.type === TYPE && typeof msg.rid === 'string' && typeof msg.op === 'string'
+}
+
+export function isReply (msg) {
+  return !!msg && msg.type === REPLY && typeof msg.rid === 'string'
+}
+
+export function request (rid, op, payload) {
+  return { type: TYPE, rid, op, payload: payload || {} }
+}
+
+export function reply (rid, result) {
+  return { type: REPLY, rid, result }
+}
+
+export function replyError (rid, code, message) {
+  return { type: REPLY, rid, error: { code, message } }
+}

package/vault/vendor/passmanager/transport/proxy.js

@@ -0,0 +1,112 @@
+// Transporte del lado que PIDE (la extensión, la app).
+//
+// Cumple `{ request(op, payload) }`, que es lo único que `RemoteVault` necesita. El
+// cliente del proxio se recibe ya construido y conectado: así esta pieza se prueba
+// con un cliente falso y no arrastra la librería entera a los tests.
+
+import { TYPE, REPLY, request as mkRequest, isReply } from './protocol.js'
+import { VaultError, CODES } from '../vault/errors.js'
+
+let counter = 0
+
+function newRid () {
+  const r = globalThis.crypto?.randomUUID
+    ? globalThis.crypto.randomUUID()
+    : String(++counter) + '-' + Math.floor(performance.now())
+  return r
+}
+
+export class ProxyTransport {
+  /**
+   * @param {object} opts
+   *   `client`      cliente de @dotrino/proxy-client ya conectado e identificado
+   *   `peerPubkey`  pubkey de FIRMA de la bóveda: por ahí la enruta el proxio
+   *   `peerEncPub`  pubkey de CIFRADO de la bóveda: a ella se sella el contenido
+   *   `myEncPrivateKey`  mi privada de cifrado, para abrir lo que me devuelvan
+   *   `timeoutMs`   cuánto se espera. Generoso a propósito: al otro lado puede
+   *                 haber alguien poniendo el dedo en el teléfono.
+   */
+  constructor ({ client, peerPubkey, peerEncPub, myEncPrivateKey, timeoutMs = 90_000 }) {
+    this.client = client
+    this.peerPubkey = peerPubkey
+    this.peerEncPub = peerEncPub
+    this.myEncPrivateKey = myEncPrivateKey
+    this.timeoutMs = timeoutMs
+    this.pending = new Map()
+
+    this.client.on('message', (_from, payload, meta) => {
+      this.#onMessage(payload, meta).catch(() => {})
+    })
+  }
+
+  async #onMessage (payload, meta) {
+    // **Ninguna respuesta en claro se acepta.** El cliente del pilar es quien abre los
+    // sobres (`requireSealed` + `myEncPrivateKey`) y marca `meta.sealed`; aquí solo se
+    // exige esa marca. Si se aceptara texto plano, cualquiera podría contestar por la
+    // bóveda: no podría leer lo que se pidió, pero sí colar una credencial falsa en un
+    // formulario.
+    if (!isReply(payload)) return
+    if (meta?.sealed !== true) {
+      this.#fail(payload.rid, CODES.UNSEALED, 'respuesta sin cifrar')
+      return
+    }
+
+    const p = this.pending.get(payload.rid)
+    if (!p) return // respuesta a algo que ya venció; se ignora
+    this.pending.delete(payload.rid)
+    clearTimeout(p.timer)
+    if (payload.error) {
+      p.reject(new VaultError(payload.error.code || 'error', payload.error.message))
+    } else {
+      p.resolve(payload.result)
+    }
+  }
+
+  #fail (rid, code, message) {
+    const p = this.pending.get(rid)
+    if (!p) return
+    this.pending.delete(rid)
+    clearTimeout(p.timer)
+    p.reject(new VaultError(code, message))
+  }
+
+  request (op, payload) {
+    const rid = newRid()
+    return new Promise((resolve, reject) => {
+      const timer = setTimeout(() => {
+        this.pending.delete(rid)
+        // No es "no hay nadie": es que nadie contestó. Suele ser el teléfono sin
+        // que nadie lo mire, y el código lo distingue para poder decirlo bien.
+        reject(new VaultError(CODES.APPROVAL_TIMEOUT, 'nadie respondió a tiempo'))
+      }, this.timeoutMs)
+
+      this.pending.set(rid, { resolve, reject, timer })
+
+      // Sale SELLADO, y de eso se encarga el pilar. Por pubkey y no por token: así
+      // entra la cola offline del proxio y la petición sobrevive a que la bóveda esté
+      // reconectando.
+      this.client
+        .sendSealed([this.peerPubkey], mkRequest(rid, op, payload), { peerEncPub: this.peerEncPub })
+        .catch(e => {
+          this.pending.delete(rid)
+          clearTimeout(timer)
+          // Se CONSERVA el código del error. Envolverlo todo en `unreachable` haría que
+          // «no tengo la llave del otro lado» y «se cayó la red» se vieran igual desde
+          // arriba, y son cosas distintas: una se arregla enlazando, la otra esperando.
+          if (e instanceof VaultError) return reject(e)
+          reject(new VaultError(e?.code || CODES.UNREACHABLE, e?.message || 'no se pudo enviar'))
+        })
+    })
+  }
+
+  /** Cancela lo que esté esperando. Se llama al cerrar el popup o al desenlazar. */
+  close (code = CODES.UNREACHABLE) {
+    for (const [rid, p] of this.pending) {
+      clearTimeout(p.timer)
+      p.reject(new VaultError(code, 'transporte cerrado'))
+      this.pending.delete(rid)
+    }
+  }
+}
+
+export { TYPE, REPLY }

package/vault/vendor/passmanager/transport/sealed.js

@@ -0,0 +1,74 @@
+// El sellado extremo a extremo vive en el PILAR del transporte
+// (`@dotrino/proxy-client/sealing`, desde 0.13.0), no aquí.
+//
+// Se escribió primero en este repo y se movió en cuanto quedó claro que la garantía
+// —que lo del usuario no llegue a los servidores de Dotrino, ni de paso— no puede ser
+// de una sola app. Este módulo queda como el punto por el que pasa el gestor, para no
+// repetir el import por todos lados.
+
+export {
+  seal, open, isSealed,
+  makeEncKeypair, importEncPrivate, exportEncPrivate,
+  setSealingPrimitives,
+} from '@dotrino/proxy-client/sealing'
+
+/**
+ * EL SOBRE que se pasan la bóveda y quien pide, en UN solo sitio.
+ *
+ * Estaba escrito dos veces —en la extensión y en la bóveda-en-pestaña de
+ * `vault.dotrino.com/vault`—, y son las dos puntas del MISMO sobre: si una cambia de
+ * forma, la otra deja de abrirlo. No falla ruidosamente, que es lo peor: la petición sale,
+ * al otro lado «no es para mí», y desde fuera se ve como que nadie respondió.
+ *
+ * Lo que sí cambia entre las dos es el DIALECTO de `@dotrino/identity`, porque no es el
+ * mismo objeto: la clase `Identity` (la que habla con el iframe) expone
+ * `getEncryptionPubkey()` y un `decrypt(remitente, miToken, sobre)` que devuelve
+ * `{ plaintext }`; el núcleo que corre dentro del service worker de la extensión expone
+ * `encryptionPubkey()` y un `decrypt(remitente, sobre)` que devuelve la cadena. Los dos
+ * son correctos y los dos se quedan; lo que no puede haber es dos ideas del sobre.
+ *
+ * @param {object} identity  cualquiera de los dos dialectos
+ * @param {object} [opts]
+ * @param {string} [opts.app='passmanager']  la marca del sobre: quien recibe lo que no es
+ *   suyo lo descarta por aquí.
+ * @returns {{seal:Function, open:Function, isSealed:Function}} el `sealing` de
+ *   `@dotrino/proxy-client` (≥ 0.13.0)
+ */
+export function identitySealing (identity, { app = 'passmanager' } = {}) {
+  // El dialecto se decide UNA vez, por lo que el objeto expone, y no por el resultado de
+  // cada llamada: así, si mañana llega un tercero que no es ninguno de los dos, revienta
+  // aquí y con nombre, en vez de devolver sobres que nadie abre.
+  const iframe = typeof identity?.getEncryptionPubkey === 'function'
+  if (!iframe && typeof identity?.encryptionPubkey !== 'function') {
+    throw new Error('identitySealing: this identity exposes neither getEncryptionPubkey() nor encryptionPubkey()')
+  }
+
+  const myEncPub = () => (iframe ? identity.getEncryptionPubkey() : identity.encryptionPubkey())
+  const openEnvelope = async (from, envelope) => {
+    const r = iframe
+      ? await identity.decrypt(from, null, envelope)
+      : await identity.decrypt(from, envelope)
+    // Un dialecto devuelve `{ plaintext }` y el otro la cadena. Nada más se admite: si
+    // llega otra cosa, se para — un `?? ''` aquí sería un sobre vacío haciéndose pasar
+    // por un mensaje.
+    if (typeof r === 'string') return r
+    if (typeof r?.plaintext === 'string') return r.plaintext
+    throw new Error('identitySealing: decrypt returned neither a string nor { plaintext }')
+  }
+
+  return {
+    async seal (msg, peerEncPub) {
+      if (!peerEncPub) throw Object.assign(new Error('no encryption key for the other side'), { code: 'unsealed' })
+      return {
+        app,
+        // Destinatarios como OBJETOS: `encrypt` expande cada uno a todos los aparatos de
+        // esa persona, y una llave suelta se le cae sin envolver nada — el sobre salía
+        // vacío, sin error, y al otro lado era «no es para mí».
+        sealed: await identity.encrypt([{ encryptionPubkey: peerEncPub }], JSON.stringify(msg)),
+        from: await myEncPub(),
+      }
+    },
+    async open (env) { return JSON.parse(await openEnvelope(env.from, env.sealed)) },
+    isSealed: (m) => !!m && m.app === app && !!m.sealed,
+  }
+}

package/vault/vendor/passmanager/vault/approval.js

@@ -0,0 +1,63 @@
+// LA APROBACIÓN, en un solo sitio.
+//
+// La piden dos bóvedas que parecen distintas y no lo son: la que responde por el proxio
+// (`VaultResponder` — el daemon, la pestaña de `vault.dotrino.com/vault`) y la que la
+// extensión lleva dentro (`GuardedVault`). Tienen que comportarse igual; que la de
+// dentro fuera la excepción y entregara sin preguntar es justo lo que el dueño mandó
+// arreglar el 2026-08-29.
+//
+// Lo que la puerta garantiza, venga de donde venga la petición (DISENO §2.0):
+//
+//   · una NEGATIVA no queda recordada como aprobación: la siguiente vuelve a preguntar
+//   · dos peticiones a la vez producen UN aviso, no dos
+//   · lo aprobado vive en memoria y muere con la bóveda: no se guarda en ninguna parte
+
+export class ApprovalGate {
+  /**
+   * @param {object} opts
+   *   `ask({ op, payload, ... })` → Promise<boolean>  cómo se le pregunta al humano.
+   *      Por defecto NO: una puerta sin quien conteste no deja pasar.
+   *   `scope(req)` → string|null  con qué llave se recuerda un sí, y con cuál se juntan
+   *      dos peticiones simultáneas. El responder pasa el APARATO, porque ahí la
+   *      aprobación es del aparato y no de cada credencial.
+   *   `remember`  si un sí vale para los siguientes. En `false` la puerta sigue
+   *      juntando las simultáneas, pero cada petición nueva vuelve a preguntar.
+   */
+  constructor ({ ask, scope, remember = true } = {}) {
+    this.ask = ask || (async () => false)
+    this.scope = scope || (() => null)
+    this.remember = remember !== false
+    this._granted = new Set()
+    this._asking = new Map()
+  }
+
+  /** ¿Pasa? Pregunta si hace falta, y recuerda el sí si le toca recordarlo. */
+  async allow (req = {}) {
+    const key = this.scope(req)
+    if (this.remember && key != null && this._granted.has(key)) return true
+
+    // Dos pestañas abriendo el mismo sitio no deben hacer sonar el teléfono dos veces.
+    const junta = key == null ? `${req.op || ''}:${req.payload?.id || ''}` : String(key)
+    if (this._asking.has(junta)) return this._asking.get(junta)
+
+    const p = Promise.resolve(this.ask(req))
+      .then(ok => {
+        if (ok && this.remember && key != null) this._granted.add(key)
+        return !!ok
+      })
+      .finally(() => this._asking.delete(junta))
+
+    this._asking.set(junta, p)
+    return p
+  }
+
+  granted (key) {
+    return this._granted.has(key)
+  }
+
+  /** Retirar lo aprobado sin apagar la bóveda. Sin argumento, todo. */
+  revoke (key) {
+    if (key == null) this._granted.clear()
+    else this._granted.delete(key)
+  }
+}

package/vault/vendor/passmanager/vault/errors.js

@@ -0,0 +1,34 @@
+// Los errores cruzan procesos (extensión ↔ vault ↔ teléfono), así que se comprueban
+// por `e.code`, NUNCA por el texto: traducir un mensaje que alguien empareja por
+// regex lo rompe en silencio. El mensaje es para el humano; el código, para el código.
+
+export class VaultError extends Error {
+  constructor (code, message) {
+    super(message || code)
+    this.name = 'VaultError'
+    this.code = code
+  }
+}
+
+export const CODES = {
+  LOCKED: 'locked',                 // la bóveda está cerrada
+  NO_KEY: 'no-key',                 // este aparato no tiene la CEK (extensión, por diseño)
+  READ_ONLY: 'read-only',           // caché local: puede leer, no escribir
+  NOT_FOUND: 'not-found',
+  DENIED: 'denied',                 // la política dijo que no
+  NOT_APPROVED: 'not-approved',     // el humano dijo que no. NO es lo mismo que `denied`:
+                                    // uno se arregla dando permiso al aparato, el otro
+                                    // volviendo a pedirlo y pulsando que sí
+  APPROVAL_TIMEOUT: 'approval-timeout', // nadie aprobó desde el teléfono
+  UNREACHABLE: 'unreachable',       // no hay bóveda al otro lado
+  NO_LINK: 'no-link',               // este perfil no está emparejado con ninguna bóveda
+  BAD_INVITE: 'bad-invite',         // eso que pegaste no es una invitación de bóveda
+  UNSEALED: 'unsealed',             // llegó (o iba a salir) sin cifrar: NO se acepta
+  UNDECIPHERABLE: 'undecipherable', // sellado, pero no para mí
+  // Estos tres se usaban desde el principio y NO estaban aquí: `CODES.NOT_ALLOWED` valía
+  // `undefined`, el error cruzaba sin código y quien pedía lo convertía en `unreachable`.
+  // O sea, «la bóveda te contestó que no» se leía en pantalla como «no hay bóveda».
+  NOT_ALLOWED: 'not-allowed',       // esta punta no tiene llave para eso (no se la envolvieron)
+  NOT_SEALED: 'not-sealed',         // la bóveda sigue en el formato viejo: hay que convertirla
+  UNKNOWN: 'unknown',               // falló algo que no trae código propio
+}

package/vault/vendor/passmanager/vault/guard.js

@@ -0,0 +1,114 @@
+// Una bóveda con la puerta puesta: la misma de dentro, pero pidiendo autorización antes
+// de soltar lo privado.
+//
+// Existe porque las tres bóvedas del ecosistema tienen que funcionar igual (dueño,
+// 2026-08-29). Las dos de fuera —el daemon y la pestaña de `vault.dotrino.com/vault`—
+// ya la tenían: se la pone `VaultResponder` al atender por el proxio. La de dentro de la
+// extensión no pasaba por ahí, porque no hay transporte de por medio, y acababa siendo
+// la única que entregaba una llave privada sin preguntar.
+//
+// **La política vive aquí, no en quien pide.** Un aparato que pide no decide nada, y en
+// la extensión «quien pide» es el mismo proceso — razón de más para que la puerta esté
+// delante de la bóveda y no repartida por cada pantalla que llama.
+
+import { VaultError, CODES } from './errors.js'
+import { privateKeysOf } from '../fields.js'
+import { projectEntry } from '../model.js'
+
+export class GuardedVault {
+  /**
+   * @param {object} inner  la bóveda de verdad (normalmente un `LocalVault` abierto)
+   * @param {object} opts
+   *   `gate`  una `ApprovalGate`
+   */
+  constructor (inner, { gate } = {}) {
+    this.inner = inner
+    this.gate = gate
+  }
+
+  /**
+   * `needsApproval: true` no es cosmético: es lo que hace que el resto del gestor trate
+   * a esta bóveda como a una de fuera —esperar a que el usuario pida ver un valor en vez
+   * de abrirlo solo— sin una sola rama nueva.
+   */
+  get capabilities () {
+    return { ...(this.inner.capabilities || {}), needsApproval: true }
+  }
+
+  async find (url) {
+    return this.inner.find(url)
+  }
+
+  /**
+   * UNA credencial, y **solo lo que se pide**.
+   *
+   * La regla, en una frase del dueño (2026-08-29): *«se pide autorización únicamente para
+   * intentar llenar un dato privado»*. Así que:
+   *
+   * - se abre la entrada **aquí dentro**, que es la bóveda mirándose a sí misma;
+   * - se mira qué de lo pedido es privado —la contraseña, el código de dos pasos, las
+   *   notas, la llave de una passkey, y los campos que el usuario marcó (§4.2)—;
+   * - si no hay nada privado entre lo pedido, **no se pregunta nada**: rellenar tu nombre
+   *   en un formulario no es sacar un secreto de ningún sitio;
+   * - y lo que sale es **solo lo pedido**. Sin esto, pedir el nombre devolvía la entrada
+   *   entera y la contraseña viajaba de propina.
+   *
+   * Sin `keys` se pide todo, así que se autoriza todo: es lo que hace falta para firmar
+   * una passkey o para copiar una contraseña desde el popup.
+   */
+  async get (id, opts = {}) {
+    const open = await this.inner.get(id)
+    const privadas = privateKeysOf(open)
+    const keys = Array.isArray(opts.keys) ? opts.keys : null
+    const pedidasPrivadas = keys ? keys.filter(k => privadas.has(k)) : [...privadas]
+
+    if (pedidasPrivadas.length) {
+      const ok = await this.gate.allow({ op: 'get', payload: { id, keys: pedidasPrivadas } })
+      if (!ok) throw new VaultError(CODES.NOT_APPROVED, 'no aprobado')
+    }
+    return projectEntry(open, keys)
+  }
+
+  /** Escribir no saca nada de la bóveda, así que no se pregunta. */
+  async put (entry) {
+    return this.inner.put(entry)
+  }
+
+  /**
+   * Cambiar unos campos tampoco: la fusión la hace la bóveda y no sale ni un valor. Es
+   * además lo que evita el fallo que tenía guardar —leer la entrada entera para escribir
+   * un campo, y perderla si esa lectura no salía—.
+   */
+  async patch (id, changes) {
+    return this.inner.patch(id, changes)
+  }
+
+  async search (q, opts) {
+    return this.inner.search(q, opts)
+  }
+
+  /** Los dominios ya viajan en claro: preguntarlos no saca nada que estuviera guardado. */
+  async sites () {
+    return this.inner.sites()
+  }
+
+  async remove (id) {
+    return this.inner.remove(id)
+  }
+
+  async list () {
+    return this.inner.list()
+  }
+
+  /**
+   * EL RESUMEN DE UN VALOR, que existe justamente para no tener que abrir nada: dice si lo
+   * que tienes escrito delante ya está guardado igual. Por eso no pasa por la puerta —no
+   * saca de la bóveda ningún valor, solo compara— y por eso hay que reenviarlo: sin esto,
+   * la bóveda sellada tenía el método y el gestor no lo veía, así que «¿ya está guardado
+   * igual?» se contestaba que no siempre y el aviso de guardar salía en cada formulario.
+   */
+  async digest (id, key, value) {
+    if (typeof this.inner.digest !== 'function') return null
+    return this.inner.digest(id, key, value)
+  }
+}

package/vault/vendor/passmanager/vault/interface.js

@@ -0,0 +1,34 @@
+/**
+ * El contrato que consumen la extensión, la consola web y la app nativa. Quién esté
+ * detrás (el vault del PC, el teléfono, o la caché local) es intercambiable — esa es
+ * la razón de que exista esta interfaz y no se lea el almacén directamente
+ * (DISENO §6.1).
+ *
+ *   find(url)  → [publicView]   qué hay para este sitio. SIN secretos: sirve para
+ *                               elegir entre varias cuentas, no para usarlas.
+ *   get(id, {keys}) → entrada abierta   UNA credencial, y solo los campos pedidos.
+ *                               Pedir algo PRIVADO exige aprobación; lo público, no.
+ *   put(entry) → publicView     crear o actualizar. Exige una bóveda de verdad.
+ *   patch(id, changes) → publicView   cambiar unos campos SIN leer la entrada antes: la
+ *                               fusión la hace quien tiene el dato. No exige aprobación
+ *                               —no sale nada— y no puede perder lo que no se tocó.
+ *   search(q)  → [publicView]   buscar por texto en TODA la bóveda, con tope. Exige un
+ *                               término que escribe una persona; no es `list`.
+ *   remove(id) → void           quitarla. La borra quien la tiene, no quien la pide.
+ *   list()     → [publicView]   la bóveda entera. Exige la CEK.
+ *
+ * `list` no está para la extensión: si pudiera listarlo todo, el "pide de a una"
+ * (DISENO §2) sería decorativo.
+ *
+ * Toda implementación expone además:
+ *   capabilities → { canWrite, canList, needsApproval }
+ */
+export const VaultSource = {
+  async find (_url) { throw new Error('not implemented') },
+  async get (_id, _opts) { throw new Error('not implemented') },
+  async put (_entry) { throw new Error('not implemented') },
+  async patch (_id, _changes) { throw new Error('not implemented') },
+  async search (_q, _opts) { throw new Error('not implemented') },
+  async remove (_id) { throw new Error('not implemented') },
+  async list () { throw new Error('not implemented') },
+}