Um mandato é um artefato, não uma configuração.
A delegação delimitada é uma capacidade dentro de Execution Authorization, não uma categoria própria. Um Task Contract enquadra a cadeia; não substitui nenhuma de suas peças. Cada passo continua produzindo seu próprio Execution Grant de uso único e seu próprio Action Receipt.
Projeto
TaskContractV1
O contrato vincula, num único objeto assinado: o tenant, os atores habilitados a agir sob ele, o Guardian e a audiência a que se dirige, a revisão, os passos, suas restrições, o orçamento e suas unidades, a janela de validade, a política e o manifesto em vigor, e o contador de revogação.
taskId · revisionIdentidade e versão. Um contrato aprovado nunca é editado no lugar: qualquer mudança num passo produz uma nova revisão que precisa ser revisada de novo.
tenant · guardianId · audienceDe quem é e qual único ponto de execução pode consumi-lo. Um mandato se dirige a um Guardian.
actors[]Cada ator vincula um identificador a uma chave e à sua thumbprint. Um passo é reclamado provando posse dessa chave contra um desafio fresco, consumido de forma atômica.
authorityÉ fixada por operação pelo protocolo. Quem chama não a escolhe nem pode degradá-la dentro do mesmo pedido, e um mandato aprovado nunca baixa o limiar de um passo.
steps[]Cada passo nomeia sua operação canônica, seu provedor, sua lista de recursos, o digest de seus parâmetros exatos, e carrega maxUses fixado em um.
budgetDurável e atômico por tenant, tarefa, revisão e passo. Comprometido significa consumido mais tudo o que está reservado cujo resultado está pendente ou incerto, para que um grant não reserve duas vezes.
issuedAt · expiresAtA janela. Depois dela nenhum passo novo é enviado; não há período de carência nem renovação de dentro da tarefa.
policyVersion · revocationVersionA política local assinada em vigor e o contador de revogação. Se o armazenamento ou a revogação estiverem indisponíveis, nenhum efeito novo sai.
A interseção continua valendo
permissão efetiva = mandato ∩ grant ∩ política local assinada ∩ restrições do adaptador ∩ orçamento ∩ identidade ∩ validade e revogação
A nuvem nunca amplia o teto local. Um mandato é mais um termo na interseção, jamais um jeito de contorná-la, e o Guardian aplica todos eles antes de contatar um provedor.
Máquina de estados
Uma tarefa ocupa exatamente um estado, e o ledger registra a transição, não a intenção.
- draft
- approved
- running
- paused
- completed
- revoked
- expired
Exclusões deliberadas
- Sem subdelegação. Um mandato, um Guardian, um orçamento; uma tarefa não pode ceder parte de si a outro ator nem levantar um segundo ponto de execução.
- Sem efeitos abertos. Um passo sem operação canônica e sem digest de parâmetros não é um passo.
- Sem autorização permanente. Todo mandato expira, e a expiração não é renovável de dentro da tarefa.
- O que o ator lê — documentos, saída de tools, conteúdo web, memória — é entrada, nunca autoridade. Não pode estender o contrato.
- O adaptador determina o efeito canônico e o estado anterior. O resumo de um agente, um esquema somente leitura ou um destino tirado do conteúdo não são aceitos como verdade.
O papel do leitor
O leitor local é explicativo. Neste perfil um achado isolado, uma abstenção, uma não avaliação ou uma leitura parcial não bloqueiam, não revogam nem forçam aprovações adicionais sobre um efeito exato já aprovado e permitido. A autoridade nunca é elevada para compensar um alerta, e nunca é baixada porque nenhum alerta apareceu. Identidade, assinatura, orçamento, precondição e revogação continuam falhando fechado — isto não é permissão para executar sem controles.
Estado
Projeto. O esquema e seus invariantes existem e estão cobertos por testes. Nenhum mandato delegado foi executado contra um provedor real, então este perfil está rotulado como simulado. Um resultado nunca é extrapolado de um mock nem de outro conector, e um conector legado testado com MFA ou quórum não credita a delegação de vários passos.
Perguntas em aberto
Os detalhes de canonicalização, os limites de tamanho e quantidade, o tratamento do relógio e a rejeição de campos desconhecidos são fixados antes de construir qualquer runtime, e publicados como vetores de teste versionados junto ao verificador. O verificador sai antes do perfil: não se emite nada que ainda não se possa verificar de forma independente.