@dotrino/vaultd 0.26.1 → 0.38.0

package/README.md

@@ -239,9 +239,16 @@ dotrino-vault caps <ID> ±permiso   # cambia lo que puede un dispositivo (+firma
 dotrino-vault revoke  <nonce>      # revoca un dispositivo (le ordena autoborrarse)
 dotrino-vault activity [n]         # bitácora de seguridad: firmas, renovaciones, enrolados, rechazos
 dotrino-vault pair --service <ns>  # empareja un SERVICIO (proxy, geo…) con acceso SOLO a sus secretos
-dotrino-vault secret set <ns> <CLAVE> <valor>   # guarda un secreto para ese servicio
-dotrino-vault secret rm  <ns> <CLAVE>           # borra un secreto
-dotrino-vault secret list                       # nombres de secretos (nunca valores)
+dotrino-vault secret set <ns> <CLAVE> <valor>   # variable del SCOPE: la comparten todos los
+                                                # aparatos que sirven ese namespace
+dotrino-vault secret set <ns> CLAVE=valor CLAVE2=valor2 …   # VARIAS de una vez (un solo aviso)
+dotrino-vault secret import <ns> [archivo.env]  # lo mismo desde un .env (o por la entrada estándar)
+dotrino-vault secret rm  <ns> <CLAVE>           # borra una variable del scope
+dotrino-vault secret device set <ID> <CLAVE> <valor>   # variable de UN aparato: solo la lee él
+dotrino-vault secret device set <ID> CLAVE=valor …     # varias de una vez
+dotrino-vault secret device import <ID> [archivo.env]
+dotrino-vault secret device rm  <ID> <CLAVE>           # borra una variable de ese aparato
+dotrino-vault secret list                       # los dos cajones, por nombre (nunca valores)
 dotrino-vault logs                 # últimas 40 líneas del servicio (journalctl; solo donde hay systemd)
 dotrino-vault version              # versión instalada (status avisa si el daemon quedó viejo)
 ```
@@ -253,6 +260,70 @@ su compromiso— y lo aprende cuando lo tecleas. El que sí recibe `deviceId` es
 El `ns` de un secreto va en minúsculas (`[a-z0-9-]`, hasta 32), la clave en
 MAYÚSCULAS_CON_GUION_BAJO (hasta 64) y el valor es texto de hasta 8 KB.
 
+#### Cargar la configuración de un servicio: JUNTA, no de una en una
+
+Guardar una variable hace que la bóveda **avise al servicio de que su configuración
+cambió**, y el servicio **sale** para que su supervisor lo levante y la lea entera y
+fresca (`watchEnv`, más abajo). Cargándolas de una en una, seis variables son **seis
+avisos**: el servicio obedece el primero y arranca con lo que hubiera puesto en ese
+momento mientras tú sigues escribiendo el resto — configuración a medias, y encima
+parece que funcionó.
+
+Por eso cargar configuración es **una sola orden**:
+
+```sh
+dotrino-vault secret import proxy .env             # el .env que ya tienes
+cat .env | dotrino-vault secret import proxy       # o por la entrada estándar
+dotrino-vault secret set proxy TURN_KEY_ID=k-123 DB_URL=postgres://…   # o a mano, juntas
+```
+
+Se leen `CLAVE=valor` (comentarios con `#`, `export` delante, comillas alrededor del
+valor). **Todo o nada**: si una línea está mal, no se guarda ninguna y se dice cuál —
+media configuración aplicada es peor que ninguna. Un `#` **a mitad de línea no corta el
+valor** (una contraseña puede llevarlo), y una clave repetida es un error, no «gana la
+última».
+
+Lo mismo desde la **TUI** (tecla `i` en Variables) y desde la **consola remota**, donde
+se edita todo lo que haga falta y se confirma con **un solo botón**.
+
+#### Las variables de entorno se ponen en DOS SITIOS
+
+| Dónde | Quién la lee | Para qué |
+|---|---|---|
+| **Por scope** — `secret set <ns> …` | todos los aparatos del perfil que sirven ese namespace | lo que es igual lo corra quien lo corra: la llave de la API, la URL de la base |
+| **Por aparato** — `secret device set <ID> …` | solo ese aparato | lo que cambia de máquina a máquina: el puerto, la URL pública, el nombre del nodo |
+
+Al servicio se le entrega **un solo bundle**: el del scope con el suyo **encima**. Si
+una variable está en los dos, **manda la del aparato** — lo específico gana, igual que
+un `.env` de máquina sobre el general. Así dos servidores sirven el mismo `ns` sin
+tener que partirlo en `proxy-1` y `proxy-2` para cambiar un puerto.
+
+Lo del aparato se indexa por su llave, que es la misma que firma la petición: no hay
+forma de pedir lo de otro. Solo se le pueden poner a un **servicio** (un miembro con
+nombre de servicio en el acta): un teléfono no pide bundles, así que guardárselas sería
+configuración muerta. Y **al quitar el aparato se van con él**.
+
+#### Pública o privada: si el VALOR puede salir de esta máquina
+
+Cada variable, esté en el cajón que esté, es **pública** o **privada**, y eso decide una
+sola cosa: si su valor puede viajar hacia la **consola remota** (`vault.dotrino.com`, un
+aparato tuyo con permiso de administrar). Al servicio que la lee le da igual: recibe las
+dos.
+
+```sh
+dotrino-vault secret set web PUBLIC_URL https://ejemplo.com --public
+dotrino-vault secret set web API_KEY sk-…              # sin bandera: privada
+dotrino-vault secret visibility web PUBLIC_URL private # cambiarlo sin tocar el valor
+```
+
+- **Se nace privada.** Y **rotar el valor conserva la visibilidad**: exponer un secreto
+  tiene que ser una decisión, no el efecto colateral de un `set`.
+- Desde la consola remota se ve el **nombre** de todas y el **valor solo de las públicas**;
+  a cualquiera se le puede poner un valor nuevo **a ciegas** (rotar una llave que no puedes
+  leer es justo para lo que sirve), y **borrar** no se delega. Lo que viaja va **cifrado**
+  con la clave de contenido del perfil: el proxy no ve nada. Detalle y límites en
+  [`docs/consola-remota.md`](./docs/consola-remota.md).
+
 ### Interfaz de terminal (TUI)
 
 Las bóvedas, los dispositivos y los secretos también se manejan desde una **interfaz
@@ -285,13 +356,25 @@ dispositivos/variables que estás viendo:
      código que muestra el dispositivo, **rechazar** y **revocar**.
    - **Scopes y variables (secretos):** ver los scopes y sus variables (nunca los
      valores), **agregar** una variable (con su scope) y **quitar** una variable o un
-     scope entero.
+     scope entero. Son las **compartidas**: las de UN aparato se ponen en la otra
+     pestaña, y esta lo dice en vez de repetirlas.
+
+   Y dentro de **Dispositivos**, con `e` sobre un servicio, sus **variables propias**:
+   las que lee solo él y le ganan a las del scope que se llamen igual. Cada cajón se
+   administra donde ya elegiste lo que lo distingue — el namespace en su pestaña, el
+   aparato en la lista de aparatos. En los dos, `t` cambia si la variable es **pública**
+     (su valor se puede ver desde la consola remota) o **privada**.
 
 Al emparejar, la bóveda **pregunta primero a qué cuenta entra el dispositivo** y
-recién después muestra el QR, que además dice de qué cuenta salió. La pregunta ofrece
-una tercera opción, «adoptar la cuenta que trae el dispositivo», que aparece
-**desactivada**: el dispositivo todavía no sabe entregar la suya. Desde la CLI ese
-camino ya se inicia con `dotrino-vault pair --adopt`.
+recién después muestra el QR, que además dice de qué cuenta salió. Se responde de tres
+formas: entrar a la cuenta activa, estrenar una nueva, o **conectar un servicio**
+(pide el namespace —`proxy`, `geo`…— y emite la invitación con scope
+`vault:secrets:<ns>`, igual que `pair --service`; el QR avisa de que lo que entrega es
+un servicio y no un aparato del dueño). Es lo que hace falta para que ese aparato
+luego tenga variables propias: sin `cn`, la bóveda no se las guarda. Una cuarta
+opción, «adoptar la cuenta que trae el dispositivo», aparece **desactivada**: el
+dispositivo todavía no sabe entregar la suya. Desde la CLI ese camino ya se inicia con
+`dotrino-vault pair --adopt`.
 
 `Esc` desde las pestañas vuelve a la lista de bóvedas; `q` sale desde cualquier
 pantalla, salvo mientras escribes en un campo o respondes una confirmación: ahí se
@@ -354,35 +437,45 @@ Si ya usabas el vault antes de esto, tu identidad de siempre se convierte sola e
 primer perfil («Perfil 1»): la misma llave, los mismos dispositivos, nada que volver
 a emparejar.
 
-### Contraseña del perfil (opcional)
+### Contraseña del perfil (opcional) — el candado es de ESTA CONSOLA
+
+Cada perfil puede llevar contraseña. Con el perfil **bloqueado**, desde la máquina de la
+bóveda no se puede **ver ni tocar nada suyo**: ni sus dispositivos, ni sus variables, ni
+el acta, ni tus datos, ni la bitácora — y tampoco emparejar, aprobar, quitar o guardar
+una variable. La CLI y la TUI contestan «bóveda bloqueada» hasta que alguien teclee la
+contraseña.
 
-Cada perfil puede llevar contraseña. **Solo se pide para EDITAR el perfil** (cambiar
-tu nombre, avatar o datos): tus dispositivos siguen firmando, leyendo y guardando
-aunque el perfil esté bloqueado — así un reinicio del PC nunca deja tus apps muertas
-esperando a que alguien teclee algo.
+Lo que **no** cambia es el servicio: **tus dispositivos ya emparejados siguen firmando,
+leyendo y guardando** aunque esté bloqueado. Eso viaja por el proxy, no por esta consola,
+y así un reinicio del PC nunca deja tus apps muertas esperando a que alguien teclee algo.
 
 ```sh
 dotrino-vault profile password     # pone o cambia la contraseña (te la pregunta)
 dotrino-vault profile password rm  # la quita
-dotrino-vault unlock               # desbloquea para poder editar
-dotrino-vault lock                 # vuelve a bloquear
+dotrino-vault unlock               # abre la bóveda en esta consola
+dotrino-vault lock                 # vuelve a cerrarla
 ```
 
+Lo único que se sigue viendo con el candado puesto es que **existe** y que está cerrada
+(`status`, `profile ls`): si no, no habría forma de saber qué abrir.
+
 El perfil se vuelve a bloquear al reiniciar el servicio. La contraseña **no se
 guarda**: solo un verificador con sal (PBKDF2), igual que el candado del navegador.
 Tiene un mínimo de 4 caracteres y, tras 5 intentos fallidos, cada intento nuevo
 espera cada vez más (hasta 5 minutos); la cuenta de fallos se guarda, así que
 reiniciar no la borra.
 
-Con el perfil bloqueado, la CLI **no** te pide la contraseña sobre la marcha:
-`profile rename`, `profile rm` y `profile password` fallan con «perfil bloqueado» y
-hay que correr `dotrino-vault unlock` antes. (La TUI sí la pide sola cuando hace
-falta.)
+Con el perfil bloqueado, la CLI **no** te pide la contraseña sobre la marcha: cualquier
+comando que mire o toque esa bóveda falla con «perfil bloqueado» y hay que correr
+`dotrino-vault unlock` antes. La TUI sí la pide sola: al **entrar** a una bóveda cerrada
+(y antes de enseñar nada) te pregunta la contraseña.
 
-Para que quede claro qué protege y qué no: evita que otro que se siente en tu máquina
-—o un dispositivo tuyo comprometido— te reescriba el perfil; **no** cifra la llave en
-el disco (de eso se encarga el cifrado en reposo, más abajo, que hoy tampoco usa la
-contraseña).
+Para que quede claro qué protege y qué no. **Protege la consola**: que otro que se siente
+en tu máquina vea o toque lo que hay en esa bóveda. **No** cifra la llave en el disco —de
+eso se encarga el cifrado en reposo, más abajo, que hoy no usa la contraseña—, así que
+alguien con acceso a esta máquina como tu usuario o como root sigue pudiendo leer los
+archivos por su cuenta. Es un candado de la puerta por la que se administra, no una
+imposibilidad criptográfica.
 
 ## Emparejar un aparato
 
@@ -463,8 +556,8 @@ La excepción, dicha sin adornos: la sincronización del **perfil**
 (`profileSet`/`profileGet`) todavía viaja **sin cifrar**, y una operación que llegue
 en claro se guarda en claro. Es deuda, no diseño.
 
-El candado de contraseña solo bloquea **editar el perfil**: guardar y leer contenido
-siguen funcionando con el perfil bloqueado.
+El candado de contraseña cierra **esta consola** (ver arriba): guardar y leer contenido
+desde tus dispositivos siguen funcionando con el perfil bloqueado.
 
 (El otro store, el «árbol de contenidos» de `vault.json`, es hoy un esqueleto: se
 puede leer con `vault.get`, pero ningún mensaje del protocolo escribe nodos.)
@@ -601,6 +694,30 @@ secreto no se puede borrar de la memoria (los strings son inmutables, no hay
 `zeroize`) y una llave se rota casi siempre *porque se filtró*: un proceso nuevo
 empieza con el heap limpio.
 
+**Y no se fía del aviso: al conectar, COMPARA.** Un aviso es un mensaje, y los mensajes
+se pierden. Si el agente está vivo pero incomunicado —se cayó el proxio, se fue la red—
+el aviso se le encola; si el corte pasa de **5 minutos** lo descarta al llegar (ventana
+de frescura) y si pasa de **24 h** ni llega (caduca en la cola). Antes ahí se acababa:
+al reconectar volvía a *escuchar*, nunca preguntaba, y se quedaba con la configuración
+vieja para siempre mientras el log decía «ignorado» como si estuviera bien. Ahora, en
+**cada conexión**, el agente pide su bundle y compara la huella con la que tiene
+aplicada; si no coincide, reacciona igual que con el aviso. El aviso sigue siendo el
+camino rápido —de segundos—; la comparación es el que no se pierde. Cubre también los
+avisos que el propio agente descarta por la gracia de arranque o el piso entre avisos, y
+la **revocación** que ocurrió mientras estaba incomunicado (la comparación recibe *no
+autorizado: revoked* y lo apaga). Comparar tiene su propio piso —`reconcileMinMs`, 30 s—
+para que una conexión que va y viene no le pida el bundle a la bóveda cada cinco
+segundos.
+
+**Y no puede volverse un ciclo de reinicios.** Lo que se compara son **dos bundles de la
+bóveda**, nunca el `.env` contra el bundle: la referencia es lo que el agente recibió, así
+que *recibir la configuración por primera vez* —tarde, que es como la recibe el proxio—
+no es un cambio. Encima, un reinicio por comparación no puede repetirse más de una vez
+por **gracia de arranque**: dentro de esos 30 s la comparación **se aplaza** (a
+diferencia del aviso, que ahí sí se descarta), de modo que ni un fallo sistemático
+lograría más de un reinicio cada 30 s — tiempo de sobra para que el supervisor lo marque
+como inestable en vez de que la máquina se pase el día arrancando.
+
 **Modos de fallo:**
 
 - **Vault caído / proxy caído** → **espera** (reintento con backoff, para siempre).

package/bin/dotrino-vaultd.js

@@ -57,16 +57,16 @@ if (process.argv.includes('--tui')) {
     // escribiendo sus logs en stdout, se los pinta ENCIMA y la deja ilegible. Se guardan
     // y se sueltan al salir, para no perder un error por el camino.
     const real = { log: console.log, error: console.error, warn: console.warn }
-    const guardados = []
-    const capturar = (nivel) => (...a) => { guardados.push([nivel, a]) }
-    console.log = capturar('log'); console.error = capturar('error'); console.warn = capturar('warn')
+    const buffered = []
+    const capture = (level) => (...a) => { buffered.push([level, a]) }
+    console.log = capture('log'); console.error = capture('error'); console.warn = capture('warn')
 
     const { runTui } = await import('../src/tui/app.js')
     try {
       await runTui()        // al salir de la TUI, se para todo: es la misma ventana
     } finally {
       Object.assign(console, real)
-      for (const [nivel, a] of guardados) real[nivel](...a)
+      for (const [level, a] of buffered) real[level](...a)
     }
     process.exit(0)
   }

package/lib/README.md

@@ -50,7 +50,7 @@ si la máquina se compromete, revocas el cert y no había nada que robar.
 ```bash
 # en el VAULT (tu PC): abres el emparejamiento del servicio y cargas sus secretos
 dotrino-vault pair --service miapp          # invitación con scope SOLO vault:secrets:miapp
-dotrino-vault secret set miapp API_KEY  sk-…
+dotrino-vault secret set miapp API_KEY  sk-…   # la comparten TODAS las máquinas del ns
 
 # en el PROYECTO/servidor: enrola esta máquina (pega la invitación)
 npx dotrino-env enroll --ns miapp
@@ -60,6 +60,17 @@ npx dotrino-env enroll --ns miapp
 dotrino-vault approve 7K3F-92Q1
 ```
 
+Si la misma app corre en **varias máquinas**, lo que cambia de una a otra (el puerto,
+la URL pública) va en el cajón **por aparato**, sin partir el `ns`:
+
+```bash
+dotrino-vault devices                                   # el ID del aparato: AB12-CD34
+dotrino-vault secret device set AB12-CD34 PORT 8443     # solo la lee ESA máquina
+```
+
+Llegan **mezcladas en el mismo bundle** —y por lo tanto en el mismo `process.env`—:
+las del scope, con las del aparato **encima** si se llaman igual.
+
 El código lo **genera el servicio** y **no viaja** por la red: el vault solo puede
 echarlo de vuelta si un humano lo tipeó. Así, un vault falso no puede enrolarte y
 aprobar a ciegas no enrola a nadie. Queda `~/.dotrino/service/<ns>/service-identity.json`
@@ -162,7 +173,7 @@ Salir en vez de recargar, por tres razones — y la primera es la de peso:
    queda corta, falla en silencio.
 3. **Es un interruptor de emergencia.** Revocar el cert de un agente ya no espera a
    que alguien se acuerde de reiniciarlo: recibe el `REVOKED` firmado, se apaga, y
-   al arrancar `fetchSecrets` recibe «no autorizado: revoked», que no se arregla
+   al arrancar `fetchSecrets` recibe «unauthorized: revoked», que no se arregla
    reintentando. Antes, revocar no le quitaba nada a un proceso ya corriendo.
 
 Defensas, porque una señal que provoca reinicios es un arma si se descuida: firma

package/lib/src/admin.js

@@ -9,8 +9,16 @@
  *
  *   sí  · ver el acta y la bitácora · iniciar un emparejamiento (mostrar el QR)
  *       · APROBAR o rechazar a quien entra · REVOCAR a un miembro
+ *       · VARIABLES DE ENTORNO: crearlas y darles valor (de un scope o de un aparato),
+ *         y ver el valor de las marcadas PÚBLICAS
  *   no  · cambiar permisos · traspasar el mando · conceder `admin`
- *       · nada de los secretos de servicios
+ *       · ver el valor de una variable PRIVADA · borrar variables
+ *
+ * SOBRE LAS VARIABLES, que es la rendija más nueva: lo que cruza la frontera no es «los
+ * secretos» sino los que su dueño MARCÓ como mostrables. Una privada se puede reescribir
+ * a ciegas desde la consola, pero su valor no sale de la máquina de la bóveda ni para un
+ * aparato tuyo con `admin`. Y los valores que sí salen viajan CIFRADOS con la clave de
+ * contenido del perfil (quien llama sella y abre): el proxy transporta y no ve nada.
  *
  * La frontera no es un capricho: un admin puede **admitir y expulsar**, pero no
  * reescribir quién manda. Así un aparato con `admin` robado hace daño **acotado y
@@ -26,7 +34,15 @@
  */
 
 /** Las únicas operaciones que existen a distancia. Lista cerrada, como las capacidades. */
-export const ADMIN_OPS = Object.freeze(['pending', 'pair', 'approve', 'reject', 'revoke', 'audit'])
+export const ADMIN_OPS = Object.freeze([
+  'pending', 'pair', 'approve', 'reject', 'revoke', 'audit',
+  // Variables de entorno: verlas (nombres siempre; valor solo de las públicas) y
+  // ponerles valor (de las dos). Borrar NO está, y es a propósito: un aparato robado
+  // no debe poder dejar sin configuración a los servicios.
+  // `var.setMany` es la MISMA operación con varias variables dentro de un solo sobre: no
+  // añade permisos, quita reinicios (ver el enrutado abajo).
+  'vars', 'var.set', 'var.setMany'
+])
 
 /** Cuánto se recuerda un nonce ya usado (el doble de la ventana de frescura). */
 export const ADMIN_NONCE_TTL_MS = 10 * 60 * 1000
@@ -40,13 +56,18 @@ export const AUDIT_MAX = 500
  * @param {(scope:string[])=>Promise<any>} o.verify  verifica cadena+cert; devuelve `{ok, device, reason}`.
  * @param {(limit:number)=>any[]} o.readActivity     últimas entradas de la bitácora.
  * @param {(pub:string)=>Promise<string>} o.deviceIdOf
+ * @param {{list:(a:object)=>Promise<any>, set:(a:object)=>Promise<any>, setMany?:(a:object)=>Promise<any>}} [o.vars]
+ *   mostrador de VARIABLES DE ENTORNO. Va inyectado porque aquí no hay cripto ni disco:
+ *   quien lo implementa (la bóveda) es quien sella con la clave de contenido del perfil y
+ *   quien decide qué valor puede salir. Sin él, las ops de variables responden que esta
+ *   bóveda no las atiende, en vez de fingir que se aplicaron.
  * @param {(ev:string, info?:object)=>Promise<void>} [o.notify]  aviso a todos los miembros.
  * @param {(op:string, info?:object)=>void} [o.audit]
  * @param {string[]} [o.defaultScope]    lo que recibe un dispositivo emparejado a distancia.
  * @param {number} [o.ttlMs]             vida del cert que se emita.
  */
 export function createAdminDesk ({
-  desk, verify, readActivity = () => [], deviceIdOf,
+  desk, verify, readActivity = () => [], deviceIdOf, vars = null,
   notify = async () => {}, audit = () => {},
   defaultScope = ['vault:sign', 'vault:read', 'vault:store'],
   ttlMs, now = () => Date.now()
@@ -127,6 +148,70 @@ export function createAdminDesk ({
         return { ok: true, result: { ok: true } }
       }
 
+      // VARIABLES DE ENTORNO. El módulo solo enruta y audita: qué valor puede salir y con
+      // qué se cifra lo decide la bóveda (`vars`), que es la que tiene la clave y el disco.
+      if (data.op === 'vars' || data.op === 'var.set' || data.op === 'var.setMany') {
+        if (!vars) return { ok: false, error: 'admin: this vault does not serve environment variables' }
+        // Un destino y solo uno: o un scope, o un aparato. Sin esto, mandar los dos dejaría
+        // que quien llama adivine dónde acabó su variable.
+        // Booleanos a propósito: comparar los VALORES («proxy» vs una pubkey) nunca da
+        // igual, así que mandar los dos destinos se colaba por el hueco.
+        const toScope = typeof data.ns === 'string' && !!data.ns
+        const toDevice = typeof data.pub === 'string' && !!data.pub
+        if (data.op === 'vars') {
+          const result = await vars.list({ by })
+          audit('admin.vars', { by })
+          return { ok: true, result }
+        }
+        if (toScope === toDevice) return { ok: false, error: 'admin: var.set needs exactly one target (ns or pub)' }
+
+        // VARIAS DE UNA VEZ. Mismo permiso y misma frontera que una sola: lo que cambia es
+        // que la bóveda las guarda juntas y manda UN aviso de cambio en vez de uno por
+        // variable — o sea, el servicio se reinicia una vez, con la configuración entera,
+        // en lugar de arrancar a medias mientras quien administra sigue escribiendo.
+        // Los nombres viajan DENTRO del sobre, igual que los valores: el proxy tampoco
+        // tiene por qué aprender cómo se llaman las variables de un servicio.
+        if (data.op === 'var.setMany') {
+          // Una bóveda anterior a esto sabe guardar de una en una y nada más. Decirlo es
+          // mejor que reventar con un TypeError que no explica qué falta actualizar.
+          if (typeof vars.setMany !== 'function') return { ok: false, error: 'admin: this vault cannot save several variables at once (update it)' }
+          if (!data.enc || typeof data.enc !== 'object') {
+            return { ok: false, error: 'admin: var.setMany needs the variables sealed with the profile content key' }
+          }
+          const result = await vars.setMany({
+            ns: toScope ? data.ns : null,
+            pub: toDevice ? data.pub : null,
+            enc: data.enc,
+            public: typeof data.public === 'boolean' ? data.public : undefined,
+            by
+          })
+          const keys = result?.keys || []
+          audit('admin.var.set', { by, ns: toScope ? data.ns : null, device: toDevice ? await deviceIdOf(data.pub).catch(() => null) : null, keys })
+          await notify('vars', { by, keys, ns: toScope ? data.ns : null })
+          return { ok: true, result: result || { ok: true } }
+        }
+
+        if (typeof data.key !== 'string' || !data.key) return { ok: false, error: 'admin: var.set needs a key' }
+        if (!data.enc || typeof data.enc !== 'object') {
+          // El valor NUNCA viaja en claro: si llega sin sobre, es un error de quien llama,
+          // no algo que se pueda «arreglar» aceptándolo.
+          return { ok: false, error: 'admin: var.set needs the value sealed with the profile content key' }
+        }
+        const result = await vars.set({
+          ns: toScope ? data.ns : null,
+          pub: toDevice ? data.pub : null,
+          key: data.key,
+          enc: data.enc,
+          public: typeof data.public === 'boolean' ? data.public : undefined,
+          by
+        })
+        audit('admin.var.set', { by, ns: toScope ? data.ns : null, device: toDevice ? await deviceIdOf(data.pub).catch(() => null) : null, key: data.key })
+        // Cambiar la configuración de un servicio a distancia no puede ser invisible: es
+        // la contrapartida de delegar (F3 de docs/consola-remota.md).
+        await notify('vars', { by, key: data.key, ns: toScope ? data.ns : null })
+        return { ok: true, result: result || { ok: true } }
+      }
+
       // QUITAR UN DISPOSITIVO se hace por `sub` (su llave): sale del acta Y se le retiran
       // todos los certificados. Las dos cosas o ninguna.
       //

package/lib/src/config.js

@@ -53,6 +53,6 @@ if (process.env.DOTRINO_ENV_WATCH !== '0') {
   try {
     await watchEnv({ ns, quiet })
   } catch (e) {
-    if (!quiet) console.error('[dotrino-env] sin escucha de cambios (%s): habrá que reiniciar a mano al rotar', e.message)
+    if (!quiet) console.error('[dotrino-env] no watch for changes (%s): a rotation will need a manual restart', e.message)
   }
 }

package/lib/src/enroll.js

@@ -104,13 +104,16 @@ export async function deviceIdOf (pub) {
  * @param {(...a:any[])=>void} [opts.log]
  * @param {(c:{deviceId:string, scope:any, label:string})=>void} [opts.onChallenge]  un dispositivo espera aprobación.
  * @param {()=>void} [opts.onPendingChange]
+ * @param {(sub:string)=>void} [opts.onDeviceRemoved]  se quitó un aparato (fuera del acta y sin papeles):
+ *   para que quien guarde algo indexado por esa llave lo suelte. Se avisa desde AQUÍ y no desde
+ *   quien llama porque a `revokeDevice` se entra por dos puertas (el PC y la consola remota).
  * @param {string[]} [opts.defaultScope]
  * @param {number} [opts.defaultTtlMs]
  */
 export function createEnrollDesk ({
   identity, iss, proxy, send, sendByPubkey,
   audit = () => {}, log = () => {},
-  onChallenge = () => {}, onPendingChange = () => {}, onAdopted = () => {},
+  onChallenge = () => {}, onPendingChange = () => {}, onAdopted = () => {}, onDeviceRemoved = () => {},
   defaultScope = ['vault:sign'], defaultTtlMs = DEVICE_TTL_MS,
   // Camino A: lo que ESTA bóveda le manda al aparato para que la meta en su acta. `encPub`
   // es su llave de CIFRADO — sin ella entra mandando pero sin poder leer el contenido.
@@ -231,7 +234,7 @@ export function createEnrollDesk ({
     }
     if (intent !== (pend.mode || 'join')) {
       audit('rejected', { what: 'enroll', reason: 'intent-mismatch' })
-      return reply(from, { type: MSG_ERROR, error: `este emparejamiento se abrió para «${pend.mode || 'join'}» y el dispositivo pidió «${intent}»` })
+      return reply(from, { type: MSG_ERROR, error: `this pairing was opened for "${pend.mode || 'join'}" and the device asked for "${intent}"` })
     }
     if (!isFresh(d)) {
       audit('rejected', { what: 'enroll', reason: 'stale' })
@@ -329,25 +332,25 @@ export function createEnrollDesk ({
     // Aprobar un emparejamiento ES admitir al dispositivo en el perfil: el cert es la
     // credencial y el acta es la política, y no tiene sentido emitir una sin la otra.
     // Las capacidades salen del scope que se pidió al emparejar (cert ∩ acta, §2.3).
-    let acta = null
+    let record = null
     try {
       if (typeof identity.admitMember === 'function') {
         const cn = scopeToCn(pend.scope)
         const caps = cn ? ['secrets'] : scopeToCaps(pend.scope)
         if (caps.length) await identity.admitMember({ pub: pend.dpub, encPub: pend.encPub || null, label: pend.label || '', cn, caps, cert, continuity: pend.continuity || null })
       }
-      acta = (await identity.profileActa?.())?.acta || null
-    } catch (e) { log('[vault] no se pudo admitir en el acta:', e.message) }
+      record = (await identity.profileActa?.())?.acta || null
+    } catch (e) { log('[vault] could not admit into the record:', e.message) }
 
     audit('enroll', { device: pend.deviceId, label: pend.label || '', scope: pend.scope })
     // Echamos el código tipeado junto al cert: el DISPOSITIVO acepta solo si coincide
     // con el que generó → una bóveda falsa (que no lo conoce) no puede enrolarlo.
     // El acta viaja con el cert: el dispositivo ya sabe de quién es el perfil al que entra.
-    reply(pend.from, { type: MSG_ENROLLED, code, cert, iss, acta })
+    reply(pend.from, { type: MSG_ENROLLED, code, cert, iss, acta: record })
     pend.state = 'DONE'
     pending.delete(pend.token)
     fire(onPendingChange)
-    log('[vault] dispositivo aprobado: %s', pend.deviceId)
+    log('[vault] device approved: %s', pend.deviceId)
     return { ok: true, deviceId: pend.deviceId, cert }
   }
 
@@ -367,39 +370,39 @@ export function createEnrollDesk ({
    * pisar una cuenta con datos, y eso no puede pasar por accidente.
    */
   async function handleActaSealed (from, p) {
-    const acta = p?.acta
+    const record = p?.acta
     const pend = [...pending.values()].find((x) => x.state === 'AWAITING_ACTA' && (x.from === from || x.dpub))
     if (!pend) return reply(from, { type: MSG_ERROR, error: 'no adoption awaiting a record' })
-    if (!acta || typeof acta !== 'object') return reply(from, { type: MSG_ERROR, error: 'record missing or unreadable' })
-    if (acta.sealer !== iss) {
+    if (!record || typeof record !== 'object') return reply(from, { type: MSG_ERROR, error: 'record missing or unreadable' })
+    if (record.sealer !== iss) {
       audit('rejected', { what: 'adopt', reason: 'not-sealer' })
       return reply(from, { type: MSG_ERROR, error: 'that record does not name this vault as the sealer' })
     }
-    if (acta.sealedBy !== pend.dpub) {
+    if (record.sealedBy !== pend.dpub) {
       audit('rejected', { what: 'adopt', reason: 'sealed-by-other' })
       return reply(from, { type: MSG_ERROR, error: 'that record was not sealed by the device of this pairing' })
     }
-    if (pend.profileId && acta.profileId !== pend.profileId) {
+    if (pend.profileId && record.profileId !== pend.profileId) {
       audit('rejected', { what: 'adopt', reason: 'other-profile' })
       return reply(from, { type: MSG_ERROR, error: 'that record belongs to an account other than the one the device announced' })
     }
 
     try {
-      const r = await identity.joinProfile(acta)
+      const r = await identity.joinProfile(record)
       if (!r?.joined) throw new Error(r?.reason || 'could not adopt')
-      audit('adopt', { device: pend.deviceId, profile: acta.profileId, seq: acta.seq })
+      audit('adopt', { device: pend.deviceId, profile: record.profileId, seq: record.seq })
       // El acta que vuelve es la que la bóveda tiene guardada: el aparato la adopta y los
       // dos quedan en la misma versión.
-      const mia = (await identity.profileActa?.())?.acta || acta
-      reply(pend.from, { type: MSG_ACTA_ADOPTED, code: p.code, acta: mia })
+      const mine = (await identity.profileActa?.())?.acta || record
+      reply(pend.from, { type: MSG_ACTA_ADOPTED, code: p.code, acta: mine })
       pend.state = 'DONE'
       pending.delete(pend.token)
       fire(onPendingChange)
-      fire(onAdopted, { deviceId: pend.deviceId, profileId: acta.profileId, seq: mia.seq })
-      log('[vault] cuenta adoptada del dispositivo %s (perfil %s)', pend.deviceId, acta.profileId?.slice(0, 12))
-      return { ok: true, adopted: true, profileId: acta.profileId, seq: mia.seq }
+      fire(onAdopted, { deviceId: pend.deviceId, profileId: record.profileId, seq: mine.seq })
+      log('[vault] account adopted from device %s (profile %s)', pend.deviceId, record.profileId?.slice(0, 12))
+      return { ok: true, adopted: true, profileId: record.profileId, seq: mine.seq }
     } catch (e) {
-      log('[vault] no se pudo adoptar la cuenta: %s', e.message)
+      log('[vault] could not adopt the account: %s', e.message)
       reply(pend.from, { type: MSG_ERROR, error: 'the vault could not adopt the account: ' + e.message })
       return { ok: false, error: e.message }
     }
@@ -435,9 +438,9 @@ export function createEnrollDesk ({
   async function revoke (nonce) {
     audit('revoke', { nonce })
     const { issued } = await identity.listDelegations()
-    const dele = (issued || []).find((d) => d.nonce === nonce)
+    const delegation = (issued || []).find((d) => d.nonce === nonce)
     const res = await identity.revokeDelegation(nonce)
-    if (dele?.sub) await emitRevoke(dele.sub, nonce)
+    if (delegation?.sub) await emitRevoke(delegation.sub, nonce)
     return res
   }
 
@@ -461,6 +464,7 @@ export function createEnrollDesk ({
           return done
         })() }
     await emitRevoke(sub, mine[0]?.nonce || null)
+    fire(onDeviceRemoved, sub)
     return res
   }