Automatización de escritorio gobernada

adk-computer-use es una capa de gobernanza sobre el servidor de automatización de escritorio de computer-use-mcp. No realiza ninguna actuación por sí misma: ordena observación, aprobación, mutación y verificación como un grafo determinista, y comprueba lo que devuelve el runtime externo.

Vinculación de respuestas

El runtime externo es la autoridad, pero sus respuestas se comprueban localmente antes de entrar en el estado del grafo. Las comprobaciones se ejecutan en el grafo de referencia para cada implementación de ComputerUseRuntime, y el adaptador de MCP las repite en su frontera de llamada directa. La deserialización tipada prueba la forma, no la procedencia — ControlLease, TargetReservation y ExecutionReceipt no tienen un constructor que haga cumplir invariantes, así que un objeto bien formado perteneciente a una sesión diferente se analiza sin problemas.

Cada respuesta se vincula de nuevo a la solicitud que la produjo:

Un desajuste produce ComputerUseError::IdentityMismatch nombrando el campo, y la respuesta se rechaza en lugar de almacenarse.

use adk_computer_use::runtime::binding::validate_lease;

// Refuses a lease that is well-formed but belongs to another session.
validate_lease(&lease, &envelope)?;

Nota: el resumen es el vínculo más fuerte disponible. args_digest es sobre lo que se otorgó la aprobación, así que un recibo que lleve un resumen diferente describe un trabajo distinto incluso cuando cada identificador coincide.

Un campo opcional que vuelve ausente se trata como una subespecificación, no como una contradicción; un campo que está presente y es diferente es un desajuste.

Revalidación en tiempo de ejecución

La vista previa no es autoridad de mutación. El grafo de referencia revalida todas las entradas de mutación en el nodo execute inmediatamente antes de llamar a execute_action:

La verificación del sobre también se ejecuta cuando devuelve la vista previa, por lo que una vista previa ya caducada nunca llega a la reserva ni a la aprobación. Se ejecuta de nuevo en la ejecución porque una interrupción de aprobación, una reserva de destino o una adquisición de concesión pueden consumir la ventana de validez restante.

ComputerUseMcpRuntime conserva exactamente el sobre devuelto por preview_action. Una llamada directa a execute_action se rechaza si cualquier campo del sobre cambia después de la vista previa, incluso cuando el ID de acción sigue coincidiendo.

Para reanudar desde un punto de control, el grafo almacena la vista previa de tiempo de ejecución en un canal de estado de solo anexado. La aprobación y la ejecución requieren que ese canal contenga exactamente una vista previa que coincida con la vista previa activa. La entrada de reanudación puede añadir estado, pero no puede reemplazar el valor controlado por el punto de control: un intento de reemplazo crea una segunda entrada y falla antes de la reserva o la mutación.

Limpieza de la reserva

Una vez que se acepta una reserva, todas las rutas terminales intentan liberarla:

• fallos en la adquisición de la concesión, la autorización, la validación, la ejecución, la recepción y la verificación;
• verificación exitosa; y
• fallos de validación o serialización de la reserva cuando el tiempo de ejecución devolvió una reserva.

El fallo principal sigue siendo el principal cuando la limpieza tiene éxito. Si la limpieza también falla, el grafo devuelve un error determinista que contiene ambos fallos. Un fallo de limpieza después de una verificación por lo demás exitosa se devuelve como error en lugar de ocultarse.

La verificación no es compromiso

ComputerUseRuntime::verify devuelve un VerificationOutcome, no un booleano:

El nodo verify del grafo escribe verified, committed y un result.verificationDetail que explica cualquier cosa por debajo de Verified.

Importante: un recibo confirmado es un reconocimiento de que la acción fue aceptada y realizada. No es evidencia de que el efecto previsto haya ocurrido. verify anteriormente devolvía receipt.status == Committed, que informaba una acción confirmada pero inefectiva como completada — desde un nodo etiquetado "verify".

Qué cuenta como evidencia

Para una postcondición que declara un digest (valueDigest, contentDigest), la verificación requiere una verification.observedDigest en el resultado del recibo que coincida con él. Para una postcondición que declara solo existencia, se requiere una verification.satisfied: true explícita.

La ausencia de evidencia nunca se trata como evidencia de éxito. Si computer-use-mcp verifica antes de emitir un recibo, ese es su contrato; este adaptador no lo asume.

Límites de arrendamiento

Se rechaza un arrendamiento a menos que se cumplan todas estas condiciones:

Los límites vacíos significan "no acotado" y autorizan cualquier destino: la ausencia de una restricción no es una restricción a nada.

Importante: la primera versión de este validador comprobaba action_budget == 0, que es el presupuesto total, por lo que un lease con action_budget: 1, actions_used: 1 pasaba mientras autorizaba nada. Tampoco leía nunca expires_at ni boundaries, así que tanto un lease caducado como un lease acotado a una aplicación diferente eran aceptados. Un vencimiento que no se puede analizar se rechaza en lugar de ignorarse: un lease cuya validez no puede establecerse no es válido.