Preflight — ¿esto le va a pedir aprobación?

kovra preflight responde una pregunta antes de que una operación se ejecute: ¿le va a preguntar a la persona, dónde y por qué? Los agentes lo usan en vez de adivinar, para dejar de decirle que algo “pedirá Touch ID” cuando no lo hará.

Es una corrida en seco en sentido estricto: nunca le pregunta a usted, nunca contacta al teléfono ni al relay, nunca materializa una referencia, nunca escribe, y nunca imprime un valor ni una huella. Decide con la misma función que usa la operación real, así que la respuesta coincide con lo que pasaría. Es un consejo, no un permiso: un nivel, la vinculación o la sesión pueden cambiar antes de la operación, que decide de nuevo.

En la línea de comandos

zsh

~ % kovra preflight run --env prod -- ./deploy.sh
run: asks for your approval
  where: Touch ID at the Mac
  secrets that make the run reviewed:
    API_TOKEN ← prod/app/token (prod, high)

La respuesta es una de estas: free (sin aprobación), free_and_notify (sin aprobación, kovra muestra una notificación), approval (le pide a usted), refused (rechazada antes de preguntar nada) o unaddressable (solo por MCP). --json imprime los mismos campos. Sale con 0 siempre que respondió, sea cual sea la respuesta; sale con un código distinto de cero solo cuando no pudo responder (una coordenada mal formada, sin vault, un .env.refs ilegible o, en phone-forget y license-deactivate, que primero consultan a kovrad, un kovrad que no responde).

Dónde preguntaría es una de estas: Touch ID, o su contraseña de inicio de sesión, en la Mac; la Mac o el teléfono vinculado (kovra Mobile, próximamente; gana la primera respuesta); solo el teléfono vinculado, donde no puede mostrarse un aviso (por SSH); solo la Mac (la llave maestra, vincular y liberar); o denegada, cuando no puede mostrarse un aviso y no hay teléfono vinculado. Lee solo lo que se sabe en local, así que no puede saber si el teléfono está silenciado, y lo dice. Por qué se da cuando la operación se rechaza (por ejemplo un secreto inject-only que show nunca revelará, o un secreto prod pedido desde la sesión de un agente).

Cubre veintiuna operaciones: run, show, code, add, set, generate, keygen, import, edit, rm, package, unpack, sign, decrypt, ssh-add, key-export, phone-pair, phone-forget, intake-fulfill <id>, init --force y license-deactivate (la liberación de la licencia de esta Mac, que se aprueba solo en la Mac). Cada una recibe los argumentos propios de la operación, nunca un valor. Abre el vault como lo hace kovra list, así que necesita la misma llave que necesita la operación.

Responde como lo haría la operación para quien la ejecuta: dentro de la sesión de un agente, kovra preflight show de un secreto prod y kovra preflight code de un TOTP prod dan refused, igual que los comandos reales.

Por MCP

La herramienta preflight responde lo mismo para las herramientas que pueden preguntar: inject_run, reveal, set, generate, delete y edit_metadata. Funciona bajo el alcance de la sesión: una coordenada fuera del alcance, o una operación que el alcance no permite, es unaddressable, sin metadatos. Un reveal que necesitaría a la persona es refused, como lo rechaza la herramienta. Nunca nombra su teléfono; dice “el teléfono vinculado”. El bloque de convenciones que escribe kovra setup le indica a los agentes consultar preflight antes de decirle que algo pedirá aprobación. Vea la referencia de herramientas MCP.

Vea también: Las reglas de aprobación, Referencia de la CLI.