Un mandato es un artefacto, no una opción de configuración.

TaskContractV1

El contrato vincula, en un único objeto firmado: el tenant, los actores habilitados a actuar bajo él, el Guardian y la audiencia a la que está dirigido, la revisión, los pasos, sus restricciones, el presupuesto y sus unidades, la ventana de vigencia, la política y el manifiesto en vigor, y el contador de revocación.

• taskId · revision

  Identidad y versión. Un contrato aprobado no se edita en el lugar: cualquier cambio en un paso produce una revisión nueva que hay que volver a revisar.

• tenant · guardianId · audience

  De quién es y qué único punto de ejecución puede consumirlo. Un mandato se dirige a un Guardian.

• actors[]

  Cada actor vincula un identificador con una clave y su thumbprint. Un paso se reclama probando posesión de esa clave contra un desafío fresco, consumido de forma atómica.

• authority

  La fija el protocolo por operación. Quien llama no la elige ni puede degradarla dentro del mismo pedido, y un mandato aprobado nunca debe bajar el umbral de un paso. El Guardian debe rechazar localmente cualquier operación que no sea elegible para delegación, aunque el grant tenga una firma válida.

• steps[]

  Cada paso nombra su operación canónica, su proveedor, su lista de recursos, el digest de sus parámetros exactos, y lleva maxUses fijado en uno.

• budget

  Durable y atómico por tenant, tarea, revisión y paso. Comprometido significa consumido más lo reservado cuyo resultado está pendiente o es incierto, así un grant no puede reservar dos veces; y presentar la misma tarea y revisión con otro contenido no debe abrir un presupuesto nuevo.

• issuedAt · expiresAt

  La ventana. Después no se envía ningún paso nuevo; no hay período de gracia ni renovación desde adentro de la tarea.

• policyVersion · revocationVersion

  La política local firmada en vigor y el contador de revocación. La revocación se comprueba como parte del propio envío, no solo antes; si el almacenamiento o la revocación no están disponibles, no salen efectos nuevos.

La intersección sigue rigiendo

permiso efectivo = mandato ∩ grant ∩ política local firmada ∩ restricciones del adaptador ∩ presupuesto ∩ identidad ∩ vigencia y revocación

La nube nunca amplía el techo local. Un mandato es un término más de la intersección, jamás una forma de esquivarla, y el Guardian tiene que aplicarlos todos antes de contactar a un proveedor; para el runtime de tareas, la brecha 03 de abajo dice dónde está eso hoy.

Máquina de estados

Una tarea ocupa exactamente un estado, y el ledger registra la transición, no la intención.

• draft
• approved
• running
• paused
• completed
• revoked
• expired

Exclusiones deliberadas

• Sin subdelegación. Un mandato, un Guardian, un presupuesto; una tarea no puede ceder una parte de sí a otro actor ni levantar un segundo punto de ejecución.
• Sin efectos abiertos. Un paso sin operación canónica y sin digest de parámetros no es un paso.
• Sin autorización permanente. Todo mandato vence, y el vencimiento no se renueva desde adentro de la tarea.
• Lo que el actor lee — documentos, salida de herramientas, contenido web, memoria — es entrada, nunca autoridad. No puede extender el contrato.
• El adaptador determina el efecto canónico y el preestado. No se acepta como verdad el resumen de un agente, un schema de sólo lectura ni un destino tomado del contenido.

El rol del lector

El lector local es explicativo. En este perfil un hallazgo aislado, una abstención, una no evaluación o una lectura parcial no bloquean, revocan ni fuerzan aprobaciones adicionales sobre un efecto exacto ya aprobado y permitido. La autoridad nunca se eleva para compensar una alerta, y nunca se baja porque no haya aparecido ninguna. Identidad, firma, presupuesto, precondición y revocación siguen fallando cerrado: esto no es permiso para ejecutar sin controles.

Brechas conocidas del runtime local

Existe un runtime local para este perfil y corre en simulación. Una revisión del 2026-09-23 encontró estas diferencias entre la especificación de arriba y el código. Quedan listadas aquí hasta que cada una se cierre con un test de regresión.

1. 01La verificación offline de un bundle de tarea toma el vencimiento del grant de un paso como motivo de rechazo, así que el bundle deja de verificar minutos después de emitido. Una prueba histórica tiene que seguir verificando después de que venza la autorización que registra.
2. 02El mismo verificador rechaza recibos correctamente firmados cuyo estado es failed, indeterminate, revoked o expired. Una tarea incompleta tiene que poder representarse como incompleta, no como inválida.
3. 03El runtime de tareas todavía no aplica la política local firmada ni una comprobación local de que la operación sea elegible para delegación. Hasta que lo haga, el techo depende de quien firma el grant.
4. 04En el runtime de tareas la revocación es opcional, y se comprueba antes del preflight del proveedor en lugar de en el momento del envío.
5. 05El ledger de tareas identifica un contrato por su digest, así que otro contrato que reutilice la misma tarea y revisión obtendría su propio presupuesto. Todavía no existe la transición de indeterminate a un resultado reconciliado.
6. 06Un bundle de tarea todavía no incluye la aprobación humana, la política local aplicada ni el claim durable, así que por sí solo no prueba la separación de funciones ni el techo que acotó la tarea.

Lo planificado — no disponible hoy

Cada punto de abajo forma parte del plan vigente. Nada de esto está disponible hoy, y cada uno aparecerá en la página de evidencia con su propio nivel —diseño, simulado o integración real— cuando se cierre.

• Aprobación ligada al mandato: un desafío de un solo uso atado al digest del contrato, la revisión, la persona que aprueba y un vencimiento. En una organización, quien solicita y quien aprueba son personas distintas, y una sesión abierta por sí sola no cuenta como una aprobación nueva.
• Una consola mínima en securestamp.online para revisar una tarea propuesta, aprobar o rechazar una revisión exacta, seguir su presupuesto y sus pasos inciertos, pedir la revocación y exportar la evidencia.
• Dos etiquetas que nunca se mezclan. Llamada restringida: solo llegan al servidor las herramientas y argumentos que el mandato permite, lo que no dice nada del efecto interno del servidor. Efecto exacto: un adaptador verificado vincula operación, recursos, parámetros y precondiciones con el resultado observado. Una ruta que esquiva al Guardian se etiqueta como no cubierta.
• El modelo ve el snapshot aprobado del nombre, la descripción y el schema de cada herramienta. Un cambio posterior detiene la tarea afectada en lugar de llegar primero al modelo.
• Más adelante, y no en el primer perfil: un diff de autoridad. Una tarea que necesita algo fuera de su mandato pide ese cambio exacto; la nueva revisión hereda lo consumido y lo incierto, y nunca reinicia el presupuesto.