Fluxo de Aprovação

A cadeia final é a união da base que venceu com todas as complementares que casaram, ordenada por stage e deduplicada (RN-AP-57, RN-AP-65). A base isDefault só vence quando nenhuma outra base casa.

Menor número vence. Sobreposição com a mesma prioridade é recusada ao publicar — verificada na aplicação, na mesma transação, com guarda parcial no banco quando ele oferecer. Se ainda assim duas casarem em execução, a submissão responde 422 APPROVAL_POLICY_AMBIGUOUS_UNPROCESSABLE.

Exatamente uma política base com critérios vazios e isDefault. O aprovador de reserva — pessoa ou grupo — é obrigatório para ativar processo com valor; opcional nos processos sem valor que nascem com política semeada, onde a resolução vazia é 422 na submissão (RN-AP-09); e proibido no BANK_ACCOUNT_CHANGE, que com menos pessoas elegíveis que o quórum fica parado com alerta (RN-AP-59, RN-AP-61). Ativar processo com valor sem reserva é APPROVAL_PROCESS_NO_FALLBACK_UNPROCESSABLE · 422.

Centro de custo e categoria, por prefixo de path. Descendentes criados depois já nascem cobertos; override no descendente é uma política de prioridade menor.

Editar publica versão nova. Instâncias vivas continuam na versão que as formou.

Passos, escopos, modos, SLA, valor avaliado, taxa de câmbio, rateio, o limiar de materialidade efetivo, a lista de excluídos, o retrato dos critérios e o authorityExceededBehavior do processo. Nada disso muda sem reavaliação explícita — mexer na configuração no meio do caminho não reembaralha aprovadores de instância viva. O limiar resolve-se uma vez, na submissão, pela mesma razão da taxa de câmbio. Único passo que nasce depois da submissão: o de controladoria da RN-AP-58, e nasce da regra congelada aqui, não de configuração nova.

Responsáveis, membros de grupo e delegação vigente são lidos na hora em que o passo ativa, não na submissão.

Removidos de toda tarefa antes de qualquer outra regra, e não há chave que desligue isso — allowSelfApproval não existe. A lista de excluídos vem do módulo dono na submissão — requisitante, quem preparou em nome de, beneficiário, último editor, proponente — e só cresce (RN-AP-60). Se o passo esvaziar, sobe um nível nos tipos de árvore ou cai no reserva nos demais; se esgotar, 422 nomeando o passo e dizendo que o excluído era o único aprovador possível — salvo no BANK_ACCOUNT_CHANGE, que não tem reserva: lá a instância fica parada com alerta (RN-AP-59). Vale para todo processo, inclusive os do Fornecedor e do Item: é esta regra — e não uma checagem no domínio — que garante "aprovador ≠ solicitante" na alteração bancária (RN-FOR-12). APPROVAL_SELF_APPROVAL_UNPROCESSABLE fica como defesa em profundidade na decisão.

422 nomeando o passo, na submissão. Só activationMinValue, a dedupe de passo de uma decisão (RN-AP-57) e a dispensa da RN-AP-68 produzem passo pulado. A guarda de grupo ou vínculo vazio vale também para expiração por vigência — e, quando o esvaziamento acontece na ativação, o desfecho é o da RN-AP-45, não o 422. "Vazio" é relativo ao modo: Quorum(n) com menos de n pessoas elegíveis é vazio (RN-AP-59).

Any, All ou Quorum(n). Rejeição encerra a instância em todos os modos — em Quorum(n), fecha em n aprovações de pessoas distintas e a primeira rejeição encerra. Votação com dissidência tolerada é modo próprio de fase 2, Vote(n), restrito aos processos que o produto declarar (BUDGET, BUDGET_CHANGE, CONTRACT); nunca uma releitura do Quorum, nunca em BANK_ACCOUNT_CHANGE.

SLA vencido notifica ou escalona. AutoApprove não existe como comportamento de escalonamento.

Em Any, a tarefa original continua viva, ambas fecham o passo, e o evento registra qual chegou primeiro. Em All e Quorum(n) a escalada substitui a tarefa do titular em vez de somar-se a ela (RN-AP-50).

Hora útil é hora dentro do expediente do tenant, no fuso ApprovalSettings.timeZone (padrão America/Sao_Paulo), em dia da semana marcado como útil e fora da lista nonWorkingDates, semeada com os feriados nacionais e editável pelo tenant. Não há calendário por estabelecimento: a lista é uma só. O tempo pausado é registrado separadamente.

Critérios de linha casam na mesma linha e critérios de fatia na mesma fatia dessa linha (RN-AP-66). Fatias do mesmo centro de custo são agregadas antes de gerar passo.

Fatia imaterial é absorvida pela maior para efeito de roteamento e continua contabilizada integralmente. Esta é a regra única do produto para materialidade, e o limiar é um só por tenant: fatia é imaterial quando fica abaixo do menor entre allocationMaterialityPercent do valor do documento e allocationMaterialityAmount — o valor absoluto é o teto do limiar. Resolvido na submissão e congelado com a cadeia (RN-AP-06). O Centro de Custo cita esta regra (RN-CC-24) em vez de redeclará-la. Materialidade é regra de roteamento, e só: o orçamento sempre vê a decomposição integral — a fatia absorvida continua sendo consumida na linha dela —, e Block numa fatia absorvida recusa a submissão do mesmo jeito.

Reconferência depois da dedupe. Quando a etapa 4 do rateio junta numa tarefa as fatias de uma pessoa, a alçada dela é comparada com o valor somado, na moeda do limite (RN-AP-52). Não cobrindo, ela sai dessas fatias; cada fatia continua a subida a partir do nó acima daquele em que ela estava, e dedupe e reconferência se repetem até alguém cobrir a soma ou a subida chegar à raiz (RN-AP-16, RN-AP-58). Vale para CostCenterOwnerUpToAmount, o tipo que compara alçada. Verificado na ativação do passo; não tem erro próprio — o resultado é o aprovador, ou a marca de alçada estourada.

Caso de ataque. Num pedido de R$ 10 milhões, 5% davam R$ 500 mil de limiar, e uma fatia de R$ 400 mil em outro centro de custo nunca passava pelo dono dele. E Carla, com limite de R$ 150 mil, recebia duas fatias somadas em R$ 160 mil — fracionamento pelo rateio. Agora o limiar é o menor dos dois (R$ 1.000 no padrão), a fatia de R$ 400 mil gera passo próprio, e a tarefa de R$ 160 mil sobe até quem cobre a soma.

Esgotada a subida, os Owners da raiz recebem a tarefa com authorityExceeded marcado na ativação, evento na trilha e aviso à controladoria antes da decisão (RN-AP-31) — e o processo decide o resto por authorityExceededBehavior: exige a decisão da controladoria em passo paralelo, ou recusa a submissão (RN-AP-58).

Titular e substituto ficam ambos na tarefa, com o id da delegação. Delegação de delegação é 422.

Toda devolução encerra a rodada. O reenvio abre rodada nova na mesma instância; cada passo é recriado e só herda a decisão anterior pela RN-AP-21 — os demais nascem Pending, e os da rodada anterior ficam Obsolete na trilha.

Rejeitar, devolver, pedir informação, reatribuir e aprovar com ressalva.

O módulo dono informa ao motor toda alteração do documento aprovado (POST /approvals/{id}/revaluate, RN-AP-43) e todo reenvio de documento devolvido, com o retrato novo e o último editor (RN-AP-60). O motor compara com o retrato da rodada anterior: no documento aprovado, com (a), (b) e (c) da RN-AP-21 é ajuste, sem rodada nova (RN-AP-71), e sem elas reabre com rodada do zero; no reenvio, decide pela RN-AP-21 o que cada passo herda. Não há tolerância de aumento, e a reavaliação não tem parâmetro por processo. No pedido que cita requisição aprovada, a reavaliação e o reenvio reconferem a soma da RN-AP-68 com o valor novo, sob a trava da instância de origem.

Na alteração de documento Approved não há herança: com (a), (b) e (c) não há rodada nova — é ajuste (RN-AP-71) —, e sem elas a rodada é do zero. No reenvio de documento devolvido, a rodada nova recria cada passo, e um passo herda a decisão aprovada da rodada anterior — inheritedFromStepId, evento approval-step.inherited, contando com o actingUserId original na RN-AP-56 — só se as três condições valem juntas: (a) o valor avaliado do assunto e o de cada fatia e de cada linha não subiu, nas duas moedas — a do documento e a funcional, convertida pela taxa da rodada (Moeda e Câmbio, RN-CUR-22) —; (b) nenhum atributo lido pelos critérios do processo mudou — centro de custo, rateio, conta contábil, categoria, tipo de item, destinação, empresa, estabelecimento, UF de entrega, fornecedor, flags do assunto, estado do orçamento —, o que se prova pelo criteriaSnapshotHash; (c) a cadeia recalculada contra as políticas vigentes (RN-AP-47) é igual ou subconjunto da anterior, comparando passo a passo por policyId, levelOrder, escopo e alvo; e, passo a passo, (d) quem decidiu passa hoje, na criação da rodada nova, nas quatro condições de elegibilidade da RN-AP-59 (1)–(4) para aquele passo — conta ativa, act:approvals e, em nível PermissionHolder, a permissão do nível — e, em passo de controle, pertencer hoje ao alvo do nível, membro vigente do papel ou do grupo —, escopo na empresa do documento, fora dos excluídos — e não violaria a RN-AP-64; e, onde a separação é por pessoa (passo de controle, BANK_ACCOUNT_CHANGE, correção de identidade), relê também a identidade verificada e a distinção por CPF: a decisão de quem perdeu a identidade verificada, ou cujo CPF deixou de ser distinto dos demais decisores e do proponente, não é herdada — aquele passo nasce Pending, em vez de a rodada nova nascer com uma decisão que o desfecho vai recusar de novo. A decisão de quem foi desligado, perdeu a permissão ou o escopo na empresa, saiu do papel ou do grupo de um passo de controle, ou virou LastEditor ao mexer numa descrição, não é herdada: aquele passo nasce Pending. Fora de (a), (b) e (c) é rodada nova do zero, com todas as decisões anteriores em Obsolete. Passo que saiu da cadeia vai a Obsolete; passo que ficou herda. No pedido que cita requisição aprovada, a cadeia recalculada traz a dispensa da base conferida de novo pela RN-AP-68 — soma com o valor novo, sob a trava da instância de origem —: se a soma estoura, a base volta, a cadeia não é subconjunto e a rodada recomeça do zero.

O retrato. Na submissão e em cada rodada o motor grava criteriaSnapshot e criteriaSnapshotHash na instância — o que entra em cada um é a RN-AP-72: os valores do documento, das fatias e das linhas e todo atributo que os critérios declarados pelo processo leem — não só os das políticas publicadas hoje, para que uma complementar publicada amanhã encontre a mudança. O retrato da rodada anterior fica no evento que a abriu. Verificado na reavaliação, dentro da transação da RN-AP-44. O retrato inclui o sinal de orçamento por fatia com que a rodada foi montada, e o motor o repassa ao contrato de desfecho: é com ele que o Orçamento distingue, na decisão final, a linha que piorou depois da rodada.

Caso de ataque. Pedido de R$ 80 mil, com a fatia de TI de R$ 60 mil aprovada por Carla, limite R$ 150 mil. Editado para R$ 250 mil, a fatia ia a R$ 187,5 mil e a assinatura dela era preservada acima da alçada; e editar a UF de entrega depois de aprovado escapava do fiscal. Agora o valor que sobe recomeça a rodada, e a UF está no retrato: mudou o hash, recomeça.

Nunca um evento de lote.

Append-only, com autor, papel pelo qual agiu, delegação em vigor e passo alcançado, gravado na mesma transação que muda o estado do agregado. O estado não é recalculado a partir dos eventos; o evento é a prova da transição (RN-AP-48).

Concorrência otimista na tarefa. A segunda pessoa é informada de quem decidiu e quando, não de um erro genérico. Não é a única trava: o que decide o avanço do passo é sempre uma leitura agregada de outras tarefas, e essa serializa na raiz pela RN-AP-44.

Não existe evento de empenho. Gravar ou liberar o Commitment, aplicar a proposta bancária, publicar o item — todo efeito da decisão que conclui acontece no contrato de desfecho, na transação da decisão (RN-AP-38). O número fica reservado para que nenhuma citação antiga aponte para outra regra.

POST /approvals:simulate (read:approval-policies) roda a mesma seleção de POST /approvals, sem criar nada, com o mesmo corpo, versões em rascunho por policyOverrides e data de referência por asOf; pessoas resolvidas são sempre as de hoje. Override que não é Draft do mesmo processo e tenant é APPROVAL_SIMULATION_OVERRIDE_UNPROCESSABLE · 422. A prévia do requisitante é POST /approvals:preview, interna, chamada pelo módulo dono sobre o próprio rascunho.

O motor consulta POST /evaluate:budget-state e obedece à overBudgetPolicy resolvida por nó, com a tolerância que o orçamento aplica. Não existe parâmetro de bloqueio no motor: dois lugares decidindo a mesma coisa divergem no primeiro documento com fatias em centros de custo diferentes — e quem erraria é o motor, que não conhece herança de política nem folga. É o princípio 6 desta spec aplicado a si mesma: o motor consome contratos, não caminha em árvores. Os sinais que o motor trata são quatro — Ok, Warning, Exceeded e Uncovered —, e Uncovered bloqueia sempre (RN-AP-53).

Onde uma segunda pessoa decide sobre o pedido de outra, o módulo dono do documento chama POST /approvals e aplica o efeito quando a instância termina. Nenhum módulo tem rota própria de aprovar ou rejeitar. Atos unilaterais com motivo (bloqueio, promoção manual, revogação, substituição, escape de duplicata, expurgo) não são aprovação. Princípio 7.

A política de reserva vem publicada pelo produto, com um nível PermissionHolder na permissão do ato no módulo dono. O tenant edita, nunca apaga a última. Processo com dinheiro continua exigindo configuração para ativar (RN-AP-03). Dia 1 igual ao de ontem, com uma diferença deliberada: quem cadastrou não aprova (RN-AP-08). Tenant em que o solicitante é o único detentor da permissão cai na RN-AP-09 — configuração de onboarding (segundo detentor ou reserva do processo), não exceção; o painel de administração avisa "processo com um único aprovador possível". O BANK_ACCOUNT_CHANGE nasce com a definição normativa da RN-AP-61, sem reserva; o SUPPLIER_REGISTRATION nasce também com a complementar semeada e travada da correção de identidade (identityCorrection, tabela de §Processos).

rejectReasonUsage e returnReasonUsage vêm do produto, por processo. Código e comentário continuam obrigatórios juntos em toda rejeição e devolução (RN-AP-19), em todo processo.

ApprovalStep.authorityExceeded e o evento approval-step.authority-exceeded são gravados quando o passo ativa nos Owners da raiz sem ninguém com alçada para o valor; nexio.approval-step.authority-exceeded vai à controladoria com a tarefa ainda aberta, a tarefa mostra a marca, o simulador a devolve por passo e /validate aponta a raiz sem Owner de autoridade ilimitada. Quem cobre sem teto é quem tem hasUnlimitedAuthority (RN-AP-51). A marca não autoriza nada sozinha: o que acontece depois é da RN-AP-58.

Todos os níveis abaixo do activationMinValue: a instância termina Approved sem tarefa e grava approval-request.approved-by-policy com a política e a versão, e o desfecho é invocado na transação do envio; o Refused recusa o envio (RN-AP-71). É a única aprovação sem pessoa do MVP — declarada na política, visível no simulador; /validate avisa a faixa sem decisor humano. Só em processo com allowPolicyApproval verdadeiro (RN-AP-54).

ApprovalGroupMember guarda usuário, grupo e período. Dois períodos do mesmo usuário no mesmo grupo não se sobrepõem — verificado na aplicação, na mesma transação, com guarda de exclusão por interseção no banco quando ele oferecer o recurso — qual banco é decisão de implementação, e ela vive na Arquitetura, não aqui. Grupo referenciado por política ativa, ou pela cadeia congelada de instância em InApproval (RN-AP-69), não pode ficar sem membro vigente: APPROVAL_GROUP_EMPTY_CONFLICT.

O SLA que "retoma na resposta" precisa de POST /approvals/{id}/answer-info, e só o requisitante da instância a chama; a recusa que "devolve ao titular" precisa de POST /approvals/{id}/assignments/{aid}/decline, e só o delegado a chama. Nenhuma das duas decide o documento, as duas geram evento.

Em nível que caminha árvore, Escalate é o responsável do nó pai. Em qualquer outro tipo, o nível declara escalationTargetType e escalationTargetRef, verificados no /validate e na publicação (APPROVAL_ESCALATION_TARGET_REQUIRED_UNPROCESSABLE). O alvo entra na cadeia projetada pelo simulador: escalar nunca amplia o conjunto de aprovadores além do que foi mostrado antes. Processo com allowEscalation = false — semente do BANK_ACCOUNT_CHANGE — recusa Escalate na publicação e no vencimento apenas lembra. Nível de árvore cujo nó é a raiz não tem pai: o vencimento vira lembrete ao titular e à controladoria, grava approval-step.sla-expired com o motivo, e nunca cai no reserva. Todo vencimento grava approval-step.sla-expired, e todo lembrete, approval-assignment.reminded.

Chave (delegante, scope, período) sem sobreposição, com scope nulo lido como "todos os processos"; verificação na aplicação, na mesma transação, e guarda no banco quando ele oferecer exclusão por interseção. validTo obrigatório, limitado a maxDelegationDays (padrão 90). Uma só por pessoa não conviveria com dez processos: impediria delegar processos diferentes a pessoas diferentes.

O passo foi resolvido com o approvalLimit de quem responde pelo nó; o delegado age em nome dele e o teto da delegação só reduz. Acima do teto, a tarefa fica com o titular. Processo com delegable = false não é alcançado por nenhuma delegação, nem pela de escopo nulo. A trilha continua gravando aprovador de direito, quem agiu e o id da delegação (RN-AP-17).

O efeito que precisa ser atômico com o ato acontece na mesma transação — pelo próprio caso de uso, por chamada síncrona declarada entre contextos (.Contracts) ou pelo contrato de desfecho do motor; o evento de domínio é publicado depois do commit e serve para notificar, medir e integrar — nunca para produzir efeito de que o ato dependa. A decisão que conclui uma instância — aprovação final, rejeição, cancelamento —, a conclusão sem decisão humana e o ajuste do documento aprovado (RN-AP-71) e a reabertura invocam o contrato de desfecho registrado para o ApprovalProcessCode, dentro da transação da decisão (RN-AP-44). O contrato é um só — instância, desfecho e, por fatia, o sinal de orçamento com que a rodada foi montada (RN-AP-21) —; quem sabe o que fazer com isso é o módulo dono, e ele devolve um de três resultados.

Applied. Decisão, transição do assunto e efeito — a Requisição transiciona e grava o Commitment, o Fornecedor aplica a proposta e inicia a carência, o Item publica — gravados na mesma transação. O evento sai depois do commit.

Refused(code). Recusa de negócio sob a trava do próprio módulo. A decisão não é gravada e a tarefa continua ativa; nenhum efeito, nenhuma transição. A tentativa fica registrada em transação própria, como ApprovalEvent approval-request.decision-refused com o código, e o POST da decisão responde com o código do módulo, sem reembrulho. O aprovador vê o motivo e escolhe: devolver com motivo, ou aguardar o que resolve o impedimento — um remanejamento de verba, uma evidência — e decidir de novo. No BANK_ACCOUNT_CHANGE, que não devolve (RN-AP-61), a escolha é rejeitar ou aguardar. Requisitante e dono do impedimento (o dono da verba, no orçamento) são avisados. Recusas conhecidas hoje: BUDGET_EXCEEDED_UNPROCESSABLE — Block estourado sob a trava das linhas de orçamento candidatas, e também RequireApproval que chegou a Exceeded depois de a rodada ter sido montada com sinal melhor —; BUDGET_UNCOVERED_ALLOCATION_UNPROCESSABLE; BUDGET_CHANGE_INSUFFICIENT_UNPROCESSABLE, do remanejamento cuja linha de origem não cobre mais o valor na decisão final; no BANK_ACCOUNT_CHANGE, BANK_CHANGE_CALLBACK_REQUIRED_CONFLICT, BANK_CHANGE_NOTICE_NOT_DELIVERED_CONFLICT, BANK_CHANGE_SIGNED_REQUEST_REQUIRED_CONFLICT (troca de canal com noTrustedPhone sem o anexo do pedido de troca assinado liberado pelo antivírus — nunca enviado, de outro tipo, revogado, eliminado ou sem veredito, RN-FOR-40), BANK_CHANGE_EVIDENCE_NOT_AVAILABLE_CONFLICT (o comprovante de titularidade ou o pedido assinado exigido na submissão foi revogado, eliminado ou deixou de estar Available, RN-FOR-35), BANK_APPROVER_IDENTITY_NOT_VERIFIED_CONFLICT (decisões da instância sem identidade verificada, ou cujos CPFs não são distintos entre si e do proponente, RN-FOR-36), BANK_CHANGE_APPROVER_IS_REQUESTER_CONFLICT (decisão vinda do CPF de pessoa ligada ao número do callback — aqui é Refused, não o 409 que o Fornecedor devolve nos atos dele) e BANK_CHANGE_IDENTITY_CORRECTION_LINKED_CONFLICT (decisão de pessoa ligada a uma correção de identidade daquele fornecedor, RN-FOR-41); e, no SUPPLIER_REGISTRATION de correção de identidade, SUPPLIER_IDENTITY_CORRECTION_ACCOUNT_MISMATCH_CONFLICT, SUPPLIER_IDENTITY_CORRECTION_IDENTITY_NOT_VERIFIED_CONFLICT e SUPPLIER_IDENTITY_CORRECTION_EVIDENCE_REQUIRED_CONFLICT (correção de identidade sem o anexo comprobatório do tipo declarado liberado pelo antivírus; o conteúdo do documento não é conferido, RN-FOR-39) — as do BANK_ACCOUNT_CHANGE e do SUPPLIER_REGISTRATION definidas no Fornecedor, a do remanejamento no Orçamento. A identidade não verificada de quem propõe não chega ao desfecho e não é Refused: é 409 no :submit do Fornecedor, e a instância nem abre. Módulo que criar recusa nova a declara na própria página, e esta lista a cita.

O motor não confere documento. Onde a regra do módulo dono exige documento comprobatório — a troca de canal de aviso sem telefone confiável e a correção de identidade do fornecedor —, a evidência é o anexo, e quem o exige é o módulo dono: que o anexo exista, seja do tipo declarado e esteja com o veredito do antivírus liberado, e que a transação da decisão grave o anexo, quem anexou, quem decidiu, a data e a hora. O Fluxo não guarda nem redeclara evidência, não confere assinatura digital, poderes do signatário, selo de cartório nem apostila, e …/assignments/{aid}/approve não tem campo para isso — o documento é escolhido pela norma da empresa, e nenhuma regra de tipo de documento por país entra aqui. Faltando o anexo, o desfecho devolve Refused com o código do Fornecedor, a decisão não é gravada e a tarefa continua ativa.

Failed. Falha técnica: rollback total, nada gravado — nem decisão, nem tentativa —, resposta com código de sufixo _UNAVAILABLE (503) ou erro interno (500). Repetir é seguro, porque a decisão carrega expectedVersion.

O sentido inverso usa o mesmo contrato. Cancelar depois de aprovado libera o efeito na transação do ato. Reabrir Approved (RN-AP-43) invoca o contrato na mesma transação, e o efeito é do módulo dono: a requisição reaberta não grava nada no razão, e a reaprovação grava só a diferença (Orçamento, RN-O45); a alteração que não reabre é ajuste, e grava a diferença na hora (RN-AP-71). Cancelar em InApproval — inclusive a contestação do fornecedor (RN-AP-61) — invoca o contrato sem efeito a desfazer. Toda devolução encerra a rodada: na rodada nova cada passo é recriado e só herda a decisão anterior pela RN-AP-21.

O que sai do processo. Publicação garantida de evento, entrega ao ERP e a espera visível de mensagem que não pode sair são requisitos registrados na página de Mensageria; a escolha de mecanismo e transporte é do estudo da plataforma.

Caso de ataque. Dois pedidos simultâneos contra a última fatia de verba: os dois aprovadores finais decidem ao mesmo tempo. Com o empenho por evento, os dois pedidos ficavam Approved e a verba ia negativa depois; com a decisão gravada e o estouro devolvido ao requisitante, a cadeia assinada sobrevivia a um efeito que não aconteceu. Agora o segundo recebe Refused(BUDGET_EXCEEDED_UNPROCESSABLE) sob a trava, a decisão dele não existe, e a tarefa continua esperando remanejamento ou devolução.

Quando o filtro por pessoa da RN-AP-59 retira, por escopo de empresa, todos os candidatos de um nível, o nível é tratado como resolvido vazio — cai no reserva da política, ou no do processo. A novidade é que isso deixa de acontecer calado: grava-se ApprovalStep.resolvedOutOfScope na ativação, com evento approval-step.resolved-out-of-scope e aviso à controladoria, na mesma forma que o authorityExceeded já usa (RN-AP-31) — porque os dois são o mesmo tipo de fato, uma cadeia que não saiu como o desenho previa.

Esta regra não deveria disparar nunca. O caminho normal é a RN-CC-30, que recusa o vínculo de quem não alcança a empresa no momento em que ele é criado. O que sobra aqui é o caso em que o escopo foi revogado depois — a pessoa mudou de área e o admin tirou a empresa dela sem lembrar dos vínculos. Nesse caso o vínculo fica dormente, e é melhor a controladoria descobrir por um aviso do que pela pergunta "por que este pedido foi parar no reserva?". O GET /approval-policies/{id}/validate acusa o mesmo antes da publicação, com o teste da RN-AP-40: o alvo tem de alcançar todas as empresas que a política alcança.

A RN-CC-30 guarda os tipos que caminham a árvore de centro de custo — o vínculo só é criado para quem alcança a empresa do nó. Os outros tipos não passam por vínculo nenhum: SpecificUser, Role, PermissionHolder e ApprovalGroup resolvem por papel, permissão ou lista, e nada neles conhece empresa. Para esses, a guarda é na publicação: GET /approval-policies/{id}/validate e a publicação recusam nível cujo alvo não tenha, em cada empresa que a política alcança — as do critério Empresa em lista, ou todas as ativas do tenant quando o critério é vazio —, pessoas elegíveis bastantes para o modo do nível. APPROVAL_LEVEL_TARGET_OUT_OF_COMPANY_SCOPE_UNPROCESSABLE · 422. Em processo cujo assunto não tem empresa, a guarda não se aplica. Na execução o filtro é por pessoa (RN-AP-59): um papel com gente de várias empresas publica, e cada documento chega só a quem enxerga a empresa dele.

O reserva alcança todas as empresas ativas do tenant. O reserva — pessoa ou grupo, da política e do processo — é o último recurso de qualquer empresa: a pessoa precisa ter escopo completo — linha vigente em todas as empresas ativas do tenant no instante da verificação (RN-EMP-27 da Empresa) —, e o grupo, ao menos um membro elegível em cada empresa ativa. Não existe concessão "todas as empresas" — o escopo é parametrizado empresa por empresa, e empresa nova é concedida só a quem a criou. Por isso o painel de administração avisa o processo cujo reserva deixou de alcançar uma empresa ativa, e a publicação seguinte recusa.

A delegação vale só onde o delegado enxerga. POST /approval-delegations exige que o conjunto de empresas do delegado contenha o do delegante — APPROVAL_DELEGATION_OUT_OF_COMPANY_SCOPE_UNPROCESSABLE · 422. Sem isso a tarefa delegada chegaria a quem toma 404 ao abrir o documento, e a delegação falharia justamente na semana de férias em que foi criada. O teto de valor continua só reduzindo (RN-AP-37); o escopo não é teto, é pré-requisito.

Um nó de centro de custo com overBudgetPolicy = RequireApproval declara uma intenção que este módulo é que cumpre: o passo a mais só existe se houver política Supplemental com o critério estado do orçamento alcançando aquele nó. As duas peças têm donos diferentes: a tela de orçamento avisa ao salvar o nó, e esta regra cobre o lado de cá. Aposentar ou deixar expirar a política sem checagem produziria um controle que morre em silêncio: o nó continua marcado, e no dia seguinte Exceeded passa como Warn.

A guarda é no /validate, e é aviso, não trava. Publicar uma Supplemental com critério de orçamento, mudar-lhe os critérios ou aposentá-la faz a tela listar os nós que ficariam órfãos, nomeando-os. Não recusa: o cliente pode legitimamente estar trocando uma política por outra, e travar a configuração o obrigaria a desmarcar todos os nós antes — o oposto de pôr o erro onde há contexto. É a mesma escolha da RN-CC-30, com a mesma razão: o erro aparece na tela de quem pode corrigi-lo, no momento em que ele nasce.

Não há código de erro nesta regra, e isso é decisão. Das quatro pontas que uma regra nova costuma ter — a regra, o campo, o slug e o erro —, esta tem três: o erro só existiria se a guarda recusasse, e ela não recusa. O que sobra em execução está na RN-AP-42.

Se a cadeia resolvida não tem nenhum passo vindo de política com critério estado do orçamento, e há fatia cuja overBudgetPolicy resolvida é RequireApproval com sinal Exceeded, a instância grava ApprovalRequest.budgetRequirementUnmet na resolução da cadeia, emite approval-request.budget-requirement-unmet na trilha e avisa a controladoria por nexio.budget.approval-requirement-unmet, com o documento ainda em aprovação. A marca fica no documento, como a de estouro já fica.

É o terceiro caso da mesma família — authorityExceeded (RN-AP-31) e resolvedOutOfScope (RN-AP-39) são os outros dois, e os três significam "a regra não saiu como o desenho previa": o produto passa, marca, e conta a quem responde pelo controle enquanto ainda dá para agir. A marca vive na instância, não no passo, porque o fato aqui é a ausência de um passo — não há onde pendurá-la.

Por que não reaproveitar o nexio.budget.overrun-recorded: ele diz "estourou" e sua audiência são os CostCenterOwners. Quem precisa saber que um controle configurado deixou de rodar é a controladoria — e os donos do nó são, nesse caso, exatamente quem se beneficiou do silêncio. Fato diferente, destinatário diferente, slug diferente.

E por que não tratar como Block: contraria o "nunca bloqueia por omissão" que esta base fixou, e transforma configuração incompleta em compra travada. A saída adotada mantém a compra andando e põe o defeito na frente de quem o corrige.

A alteração que não toca o que a aprovação leu não sai de Approved: é ajuste, sem rodada (RN-AP-71). A instância tem duas saídas declaradas de Approved: Approved → InApproval por revaluate da alteração que não é ajuste, com rodada do zero, e Approved → Cancelled por cancel. As duas gravam evento — approval-request.reopened e approval-request.cancelled, o único nome do cancelamento — e a reabertura incrementa roundNumber na instância; os passos da rodada anterior vão a Obsolete e os novos nascem com a rodada nova. Não nasce estado no enum. Reopened só diria "já esteve aprovado", e isso a rodada já conta; um estado a mais obrigaria todo módulo consumidor a tratá-lo, para não dizer nada que InApproval + roundNumber > 1 não diga.

A reabertura passa pelo contrato de desfecho no sentido inverso, na mesma transação (RN-AP-38), e o módulo dono decide o efeito — a requisição reaberta mantém o comprometido preso, e a reaprovação grava só a diferença (Orçamento, RN-O45). Documento em moeda diferente da funcional é reconvertido nesse desfecho, que devolve a conversão nova com que a rodada do zero é montada (RN-AP-72). No BANK_ACCOUNT_CHANGE não há reabertura: revaluate é APPROVAL_TRANSITION_NOT_ALLOWED_CONFLICT · 409. Sem a transição escrita, cada módulo transacional improvisaria a sua — uns reabrindo a instância, outros criando uma segunda —, e a pergunta "quantas rodadas este pedido teve", que é o que justifica a instância única, deixaria de ter resposta no primeiro que escolhesse diferente.

ApprovalRequest tem version (int) e toda decisão passa expectedVersion; divergência é APPROVAL_REQUEST_VERSION_CONFLICT · 409, e a resposta traz o estado atual para que a pessoa releia e decida de novo. O fechamento do passo e a ativação do seguinte acontecem dentro da mesma transação da decisão — a mesma em que a RN-AP-38 grava o efeito.

Por que a raiz e não a tarefa. A RN-AP-24 já protegia duas decisões na mesma tarefa, mas o que decide o avanço é sempre uma leitura agregada de outras tarefas: contar aprovações em Quorum(n), fechar All, marcar as demais Obsolete em Any, ver que todas as fatias do nível fecharam. Quorum(2) com três pessoas decidindo ao mesmo tempo: duas transações leem uma aprovação, ambas gravam duas, ambas fecham o passo, ambas invocam o contrato de desfecho — e a verba é empenhada duas vezes. Simétrico: duas fatias paralelas ativam o nível seguinte duas vezes, e uma rejeição concorrente com a última aprovação deixa a instância Rejected com o efeito de aprovação aplicado. Um token por tarefa não pega nenhum dos três, porque em nenhum deles duas transações escrevem a mesma tarefa.

O sequence do ApprovalEvent é alocado nesta mesma transação, que é o que faz a trilha ter ordem total dentro da instância (RN-AP-48). O custo é o esperado: as decisões de uma instância viram fila. É o preço certo — a publicação de política já paga o equivalente com bloqueio de linha, e uma instância recebe unidades de decisão por dia, não milhares.

A RN-AP-07 resolve as pessoas na ativação do passo, e o tempo passa entre a submissão e a ativação: o validTo do último membro do comitê vence, o papel fica sem detentor, o Owner deixa de ser vigente. Percorrida a ordem completa da resolução, um passo que ativa vazio por esse motivo marca ApprovalStep.resolvedEmptyOnActivation, cai no aprovador de reserva — o da política, depois o do processo —, grava approval-step.resolved-empty-on-activation e avisa a controladoria, no mesmo molde do authorityExceeded (RN-AP-31) e do resolvedOutOfScope (RN-AP-39). É o quarto caso da família "a cadeia não saiu como o desenho previa".

A ativação vazia nunca derruba a decisão de quem acabou de aprovar. É o ponto inteiro da regra: se a ativação do nível 2 devolvesse 422 dentro do POST de aprovação da Carla, ou a aprovação legítima dela seria revertida e ela veria erro numa ação correta, ou a instância ficaria InApproval sem nenhuma tarefa aberta, invisível em toda fila, sem SLA correndo, sem evento e sem aviso. Expired não existe no enum, de propósito: a resposta é o desfecho declarado. O 422 da RN-AP-09 continua sendo a resposta da submissão, onde quem chama é o módulo dono e ainda dá para recusar sem desfazer nada.

E avisa antes de vencer. A guarda de grupo ou vínculo vazio da RN-AP-09 vale também para expiração por vigência: membro de grupo, vínculo de centro de custo ou delegação cuja validTo se aproxima, em grupo ou nó referenciado por política ativa, gera aviso de vencimento com antecedência. Corrigir um cadastro antes de ele vencer é barato; descobrir pelo passo que caiu no reserva é o caminho que esta regra existe para tornar raro. Se o reserva também esvaziar — ou não completar o modo —, o passo fica parado com alerta até o cadastro ser corrigido (RN-AP-59): nunca é pulado e nunca derruba a decisão anterior.

ApprovalScopeMode tem três valores — Document, Line e Slice. Um nível com scopeMode = Line gera um passo por linha do documento que satisfaz os critérios de linha da política de origem do nível (RN-AP-66), com scopeRef = id da linha e scopeAmount = valor da linha; os passos de linha do mesmo nível são paralelos entre si, como os de fatia. A materialidade não se aplica — ela dispensa fatia, e o que faz uma linha entrar aqui não é o valor dela, é o critério: uma linha interestadual de R$ 300 passa pelo fiscal exatamente como uma de R$ 300 mil. A dedupe é por (pessoa, linha), não por (pessoa, fatia): quem responde pelo fiscal de duas linhas recebe duas tarefas, porque o que ele examina é a linha, uma de cada vez.

O casador roda de novo contra o conjunto vigente na data da reavaliação, não contra o congelado na submissão. A instância guarda as duas tuplas — a do snapshot original e a da rodada corrente, cada uma com policyId e policyVersion —, e o evento approval-request.revaluated registra o que mudou entre elas. A RN-AP-06 continua íntegra: o que ela congela é o documento que ninguém reavaliou.

Era a única leitura que fechava as duas afirmações. O princípio 1 diz que editar política não muda documento em andamento; a RN-AP-20 manda reavaliar quando muda a categoria porque isso pode acionar controle complementar que não existia — e um controle que não existia na submissão só entra se o casador olhar para o presente. Congelar as versões antigas na reavaliação seria pior na prática: a devolução reenviada é o caminho mais comum do produto, e o documento voltaria a circular sob a regra que o cliente acabou de corrigir. Editar política não muda documento que não foi reavaliado — é o que o princípio 1 protege.

Consequência na RN-AP-21: é a cadeia recalculada contra as vigentes que se compara com a anterior, passo a passo por policyId, levelOrder, escopo e alvo — sem o levelOrder, um nível que mudou de posição herdaria a assinatura de outro degrau. Se a cadeia ganhou passo, a rodada recomeça do zero — inclusive quando a base dispensada do pedido volta porque a soma da RN-AP-68, reconferida com o valor novo sob a trava da instância de origem, estourou.

ApprovalEvent tem tabela de campos, enum fechado de ações e chave de ordenação (approvalRequestId, sequence), com o sequence monotônico dentro da instância e alocado na transação da decisão (RN-AP-44). Ordenar por occurredAt é proibido: aprovação em lote grava N eventos no mesmo instante, e fatias paralelas fecham juntas — o empate é a regra, não a exceção.

Imutável quer dizer sem rota de escrita. Não há PUT, não há DELETE e não há soft delete — a exclusão lógica que o resto do produto herda da plataforma não se aplica aqui, e a exceção é declarada. Corrigir um evento é gravar outro que o corrija, apontando no metadata o sequence corrigido. Mesma disciplina do razão orçamentário, mesma razão: trilha editável não prova nada, e a promessa "aprovação tem prova quando a auditoria pergunta quem autorizou" precisa ser verificável, não afirmada.

O que é coluna e o que é metadata: tudo por que a GET /approvals filtra é coluna. O metadata guarda o que é específico da ação — o alvo da reatribuição, o que mudou na reavaliação, qual passo a escalada acrescentou. Pôr ali um campo de filtro é como o esquema se perde de novo.

Uma ApprovalDelegation vale para os passos que ativam enquanto está vigente (RN-AP-07): a tarefa nasce com o titular como aprovador de direito e o delegado como quem age, e grava approval-assignment.delegated com o id da delegação. Tarefas Pending do titular no início da vigência não são transferidas; o fim da vigência não devolve tarefas. O SLA é do passo e não muda por delegação.

Em Any, a escalada acrescenta um caminho e a tarefa do titular continua viva (RN-AP-12). Em All e Quorum(n) a escalada substitui a tarefa do titular, que vai a Obsolete. O número de pessoas distintas que o modo exige não muda nunca — é o que o modo significa.

O caso que fecha: num Quorum(2) de quatro olhos, com a escalada somando, o titular atrasa, o escalado entra, e o quórum fecha com uma assinatura de quem decidiu e outra de quem entrou por decurso de prazo. É a superfície que a spec já fecha no BANK_ACCOUNT_CHANGE com allowEscalation = false e deixava aberta no cadastro de fornecedor PF e no item crítico, que também usam quatro olhos. Trancar o processo inteiro resolveria um caso e deixaria os outros; compor com o modo resolve todos, e não custa configuração nenhuma ao cliente.

O alvo da escalada passa por RN-AP-08, alçada e escopo de empresa, como o alvo original: o requisitante nunca decide a própria instância nem por escalonamento; o escalado precisa cobrir o scopeAmount do passo, ou o passo herda authorityExceeded e segue authorityExceededBehavior — exige a controladoria, porque na ativação nunca se recusa (RN-AP-31, RN-AP-58); e quem não alcança a empresa do documento cai na RN-AP-39. Uma porta que a submissão fecha e o vencimento abre não está fechada.

CostCenterAssignment.approvalLimit nulo significa sem alçada — o vínculo não cobre valor nenhum, e a resolução sobe a árvore. Quem decide sem teto é quem tem hasUnlimitedAuthority = true, campo próprio, preenchido de propósito. As duas páginas dizem a mesma coisa: o Centro de Custo é dono dos campos, este documento é dono da leitura que o motor faz deles.

Por que limite nulo não é ilimitado. O campo é opcional: se o filtro aceitasse "limite nulo (sem teto próprio)", todo vínculo criado sem preencher a alçada — importação, migração do managerUserId, admin com pressa — nasceria com autoridade infinita do ponto de vista do motor, e o /validate chegaria a exigir uma raiz com Owner de limite nulo. Ariba, Coupa e Protheus tratam limite ausente como zero. Autoridade infinita tem de custar um ato de cadastro, não um campo em branco — e o /validate aponta a raiz sem ninguém de autoridade ilimitada, que é a mesma checagem com o sinal certo.

approvalLimit anda com approvalLimitCurrency, obrigatória quando o limite está preenchido — inclusive no nó corporativo, que não tem empresa. A comparação converte o valor da fatia ou da linha para a moeda do limite, usando a taxa do documento — a da submissão ou a da última rodada nova (Moeda e Câmbio, RN-CUR-22) —, e o ApprovalEvent da decisão grava a exchangeRate e a rateDate usadas. Submeter documento cuja moeda não tem par de conversão vigente contra a moeda de um limite que a cadeia precisa avaliar é recusa declarada — APPROVAL_LIMIT_CURRENCY_NOT_CONVERTIBLE_UNPROCESSABLE, repassado da Moeda sem reembrulho —, nunca comparação silenciosa. O código genérico de conversão sem par cadastrado é outro, e não é este.

Moeda funcional BRL, documentos multimoeda. A functionalCurrency da empresa é BRL na v1; documentos, preços e limites de alçada seguem em qualquer ISO 4217. A regra de comparação é uma só: converte-se para a moeda do limite, com a taxa congelada. Com um documento em USD e o limite do nó corporativo em BRL, comparar sem conversão declarada seria comparar moedas diferentes exatamente no ponto em que a alçada decide.

A taxa é do documento, e o razão herda. A conversão acontece na submissão e se renova só no ato que abre rodada nova — reenvio de devolvido e reabertura com rodada do zero —; o ajuste e as decisões usam a taxa gravada (Moeda e Câmbio, RN-CUR-22); todo movimento do razão originado por ele herda exchangeRate e rateDate do documento, e a resolução própria de taxa do Orçamento vale só para movimento sem documento de origem. O Commitment é gravado depois da submissão; com resolução no movimento, a verba consumiria um número diferente do que foi aprovado.

POST /evaluate:budget-state devolve quatro sinais — Ok, Warning, Exceeded e Uncovered —, e os quatro são valores do critério estado do orçamento. Uncovered recusa a submissão sempre, independentemente da overBudgetPolicy resolvida no nó: fatia lançada contra dimensão orçamentária inexistente não é estouro tolerável, é ausência de verba, e quem o diz é o Orçamento — o motor obedece, como manda a RN-AP-27.

Sem esta regra, das duas uma: ou o motor deixaria passar fatia contra dimensão inexistente, ou devolveria um erro que nenhum contrato declara. A recusa é repassada do orçamento, porque quem produz o fato é o mesmo módulo — e o código é o BUDGET_UNCOVERED_ALLOCATION_UNPROCESSABLE, que o Orçamento declara para este sinal, não o BUDGET_EXCEEDED_UNPROCESSABLE. São dois fatos diferentes — um tem tolerância e política, o outro não tem contra o que medir —, e cada um tem o seu código.

Cada ApprovalProcess declara, do produto e fora do alcance do tenant: se tem valor, se o assunto tem empresa, allowPolicyApproval, allowReturn (falso só no BANK_ACCOUNT_CHANGE), minDistinctApprovers, os tipos de aprovador e os escopos admitidos e, no BANK_ACCOUNT_CHANGE, as travas da RN-AP-61. Os valores estão na tabela Núcleo de controle. GET /approval-processes os devolve; PUT /approval-processes/{id} não os aceita — corpo que tente mudá-los é APPROVAL_PROCESS_CONTROL_LOCKED_CONFLICT · 409. Mudá-los é mudança de spec.

Verificado na publicação de toda versão de política, e listado antes pelo /validate: (a) nível com tipo ou escopo não admitido → APPROVAL_LEVEL_NOT_ADMITTED_UNPROCESSABLE · 422; (b) critério faixa de valor ou activationMinValue em processo sem valor → APPROVAL_POLICY_VALUE_NOT_APPLICABLE_UNPROCESSABLE · 422 — sem valor, a comparação com nulo não tem definição, e deixá-la indefinida é deixar o nível ligar ou desligar ao gosto da implementação; (c) com allowPolicyApproval falso, política cuja cadeia possa terminar sem decisão humana → APPROVAL_POLICY_APPROVAL_NOT_ALLOWED_UNPROCESSABLE · 422; (d) com minDistinctApprovers = k maior que 1, toda política base precisa de um nível sem activationMinValue em Quorum(n) com n ≥ k → APPROVAL_POLICY_DISTINCT_APPROVERS_UNPROCESSABLE · 422. É a única forma de garantir k pessoas na publicação: All depende de quantas o alvo resolve, e dois níveis podem cair na mesma pessoa. Complementares só acrescentam.

Defesa na execução. Na submissão, resolução que terminaria Approved sem pessoa em processo com allowPolicyApproval falso é recusada com o mesmo código de (c); na decisão, a rodada não conclui com menos de minDistinctApprovers pessoas distintas (RN-AP-56).

Caso de ataque. Um administrador troca o Quorum(2) da alteração bancária por Any, ou põe activationMinValue de R$ 0,01 em todos os níveis para a troca de conta terminar aprovada pela política. Agora a publicação recusa as duas versões, por (d) e por (b), antes de existir qualquer instância.

Em todos os processos, quem publica uma versão de política não é quem a criou nem ninguém que a tenha editado em qualquer momento do rascunho. A versão guarda createdByUserId, editedByUserIds — lista que cresce a cada edição do rascunho — e publishedByUserId; POST /approval-policies/{id}/publish por quem está no autor ou na lista é APPROVAL_POLICY_SELF_PUBLISH_FORBIDDEN · 403, verificado na transação da publicação. Desativar política é publicar versão com vigência encerrada, e passa pela mesma regra. As políticas semeadas nascem publicadas pelo produto; a primeira edição do tenant já exige duas pessoas.

A prova e o aviso. Publicar é ato de controle: a versão publicada é imutável (RN-AP-05) e carrega, além de autor, editores e publicador, o diff de critérios e níveis contra a versão que aposentou — gravado na mesma transação, isolado pelo tenant como toda linha de política. Depois do commit sai o evento approval-policy.published, e a controladoria recebe aviso obrigatório com o diff.

Caso de ataque. Um administrador sozinho publica, à noite, a versão que tira a controladoria da faixa acima de R$ 500 mil, aprova o que queria e republica a versão antiga de manhã. Agora a primeira publicação é recusada sem uma segunda pessoa, e cada versão publicada chega à controladoria com o diff.

Invariante do agregado ApprovalRequest, verificada na decisão, dentro da transação da RN-AP-44: (a) num passo, duas aprovações nunca têm o mesmo actingUserId; (b) nenhum actingUserId está na lista de excluídos (RN-AP-60); (c) a rodada não conclui com menos de minDistinctApprovers pessoas distintas, contadas as decisões herdadas (RN-AP-21). Violação de (a) ou (c) é APPROVAL_DISTINCT_APPROVER_UNPROCESSABLE · 422; de (b), APPROVAL_SELF_APPROVAL_UNPROCESSABLE · 422. Conta quem agiu, não o aprovador de direito.

Por que no agregado, e também nas rotas. Delegação, reatribuição e escalonamento trocam quem age em momentos e rotas diferentes; a garantia é uma só, na raiz, e as rotas recusam antes para a pessoa não ver erro na hora de decidir. A delegação (RN-AP-49) só entrega a tarefa a delegado elegível para o passo (RN-AP-59), fora dos excluídos e sem tarefa ou decisão no mesmo passo — senão a tarefa fica com o titular. A reatribuição com destino nessas condições é APPROVAL_REASSIGN_TARGET_UNPROCESSABLE · 422, e o alvo da escalada passa pelas mesmas guardas (RN-AP-50). Criar delegação exige delegado com act:approvals e conta ativa, diferente do delegante (APPROVAL_DELEGATE_NOT_ELIGIBLE_UNPROCESSABLE · 422).

Delegação criada por terceiro. Quem tem create:approval-delegations e cria a delegação de outra pessoa pratica ato de controle: a delegação grava quem a criou, e o delegante recebe aviso obrigatório. Não exige aceite — o aviso é o controle.

Caso de ataque. Os dois membros de um Quorum(2) delegam para a mesma pessoa, e um voto vira dois; a delegação cai no requisitante; um administrador cria a delegação do CFO para si mesmo. Agora a segunda tarefa não vai ao mesmo delegado, e se chegasse a segunda aprovação seria recusada por (a); o requisitante é excluído e nunca recebe; o CFO recebe o aviso com o nome de quem criou.

Decidida na ativação do passo, pelo actingUserId: quem agiu no degrau imediatamente anterior da mesma rodada (o stage anterior, RN-AP-65) sai das tarefas do passo que ativa. Passo de controle nunca é pulado — toda complementar, o passo de controladoria e o quórum do BANK_ACCOUNT_CHANGE (RN-AP-64): a pessoa sai dele, e os demais decidem. Decisão tomada em passo de controle nunca cobre outro passo: quem decidiu controle sai das tarefas do passo seguinte, de base ou de controle, e o passo continua com os demais, sem ir a Skipped (RN-AP-64). Só a decisão tomada em passo comum cobre passo comum de uma decisão (Any): o passo vai a Skipped com o motivo e approval-step.skipped. Em passo de mais de uma (All, Quorum(n)), a pessoa sai do conjunto, o passo continua com as demais, e a decisão anterior dela não conta para o modo; se sobrarem menos elegíveis do que o modo exige, vale a RN-AP-59. deduplicateConsecutive é do tenant, por processo, e falso e travado no BANK_ACCOUNT_CHANGE.

Caso de ataque. Quem aprova a fatia no degrau anterior está também no papel da complementar de verba estourada, Any: se a dedupe pulasse esse passo, a decisão da base cobriria o controle. E, num quórum antecedido por um passo Any sobre a mesma permissão, pular o quórum fecharia com uma assinatura. E se a decisão de controle cobrisse o passo comum seguinte, num remanejamento acima de R$ 50 mil o CFO que decide a complementar de investimento (stage 15), sendo membro da controladoria, levaria a base Role(Controladoria) · Any (stage 20) a Skipped — uma pessoa fecharia controle e base. Agora a pessoa sai do passo de controle e outra decide, o quórum nunca é pulado, e quem decidiu controle sai do passo seguinte em vez de cobri-lo.

authorityExceededBehavior, por processo, tem dois valores: RequireControllerApproval (semente) e Refuse. Vale para dois fatos: a subida que chega à raiz sem cobrir (RN-AP-16) e o passo que cai no aprovador de reserva em processo com valor — o reserva não tem alçada verificada, então aprovar por ele é alçada estourada por definição. Aprovar no topo só com aviso não existe: é controle só detectivo.

RequireControllerApproval. Na ativação do passo marcado, o motor cria no mesmo nível um passo paralelo Role(Controladoria) · Any — o papel funcional que a Notificação semeia no tenant —, com o mesmo escopo e valor, controlOfStepId apontando o passo marcado, e grava approval-step.controller-required. O nível só avança com os dois fechados, e quem decide o de controladoria é pessoa distinta de quem decide o marcado (RN-AP-56). Controladoria sem ninguém elegível não cai no reserva — o reserva não controla o reserva —: o passo fica parado com alerta (RN-AP-59). O simulador mostra o passo extra antes da submissão.

Refuse. Submissão cuja cadeia projetada já estoura ou já cai no reserva é recusada com APPROVAL_AUTHORITY_EXCEEDED_UNPROCESSABLE · 422, nomeando o passo, o valor e o maior limite encontrado. Estouro que só aparece na ativação — o vínculo mudou depois da submissão — não recusa, porque a ativação nunca derruba a decisão de quem acabou de aprovar (RN-AP-45): segue como RequireControllerApproval.

Toda tarefa que vem do reserva, em qualquer processo, tem origin = ByFallback e grava approval-step.resolved-by-fallback. O reserva é pessoa ou grupo (fallbackApproverType = User ou ApprovalGroup), resolvido pessoa a pessoa (RN-AP-59).

Caso de ataque. Num tenant com a árvore incompleta, o gestor da raiz — ou a pessoa única de reserva — aprovava um pedido de R$ 2 milhões sem ninguém com alçada para isso, e a controladoria só sabia pelo aviso. Agora o pedido não conclui sem a decisão de uma pessoa da controladoria, distinta de quem aprovou no topo; no tenant que escolheu Refuse, nem é submetido.

Toda resolução de tarefa — ativação, delegação, reatribuição, escalonamento e reserva — filtra cada pessoa candidata por quatro condições, lidas no momento: (1) conta ativa no tenant; (2) act:approvals e, em nível PermissionHolder, também a permissão do nível; em passo de controle (RN-AP-64), toda pessoa — o titular resolvido na ativação, quem chega por delegação, reatribuição ou escalonamento e quem entra pelo reserva — precisa pertencer hoje ao próprio alvo do nível: membro vigente do papel ou do grupo, detentor da permissão, a própria pessoa específica ou quem tem o vínculo vigente no nó; alvo de pessoa específica ou de árvore não admite ninguém de fora, e act:approvals sozinho não basta; (3) escopo por empresa que inclui a empresa do documento — por pessoa, nunca por nível; nos processos cujo assunto é cadastro do tenant e não tem empresa (SUPPLIER_REGISTRATION, SUPPLIER, BANK_ACCOUNT_CHANGE, ITEM), a condição não se aplica e vale só a permissão, como em toda leitura de cadastro do tenant; (4) fora da lista de excluídos (RN-AP-60). Quem não passa não recebe tarefa. Em passo de controle, a delegação que falha em (2) deixa a tarefa com o titular; a reatribuição é recusada com APPROVAL_CONTROL_STEP_TARGET_UNPROCESSABLE · 422; a escalada não acrescenta quem está fora do alvo — sem ninguém, segue só o lembrete —; e o reserva só completa o passo com quem pertence hoje ao alvo do nível: quem está fora não entra, e o passo fica parado, como em toda resolução vazia, em vez de ser completado por fora do alvo. Na decisão as quatro são relidas: quem perdeu a elegibilidade depois de receber a tarefa tem a decisão recusada com APPROVAL_APPROVER_NOT_ELIGIBLE_FORBIDDEN · 403 — inclusive o titular de passo de controle que saiu do papel ou do grupo do nível, mesmo mantendo act:approvals; a herança da rodada nova relê o mesmo (RN-AP-21 (d)).

Menos elegíveis que o modo é resolução vazia. Any e All com zero pessoas, Quorum(n) com menos de n. Segue a ordem da resolução: na submissão, reserva e então APPROVAL_NO_APPROVER_UNPROCESSABLE · 422; na ativação, reserva com a marca da RN-AP-45. O reserva completa o conjunto, nunca reduz o quórum. Se nem com ele o modo se completa, o passo fica parado: Active, com awaitingEligibleApprovers verdadeiro, evento approval-step.stalled e alerta ao administrador do tenant e à controladoria. Sai daí por POST /approvals/{id}/steps/{stepId}/resolve, que refaz a resolução depois de o cadastro ser corrigido (APPROVAL_STEP_NOT_STALLED_CONFLICT · 409 se o passo não está parado), ou pelo cancelamento vindo do documento. No BANK_ACCOUNT_CHANGE, que não tem reserva, menos de duas pessoas elegíveis deixa a instância parada já na submissão — não 422, porque a proposta precisa existir para ser vista e contestada.

Dependência de plataforma. A resolução de Role e PermissionHolder precisa perguntar ao GrydAuth "quais usuários ativos deste tenant detêm esta permissão, direta ou por papel", e essa consulta não existe na plataforma. Está na demanda de plataforma como o item P8 — problema, requisito e critério de aceite —; bloqueia a primeira instância com nível PermissionHolder — que é a semente de quatro processos.

Caso de ataque. Usuário desativado, ou sem act:approvals, continuava recebendo e decidindo tarefas porque o papel ainda o listava; num Quorum(2) com uma pessoa só no papel, a regra calava; num grupo multiempresa, um Role com pessoas de escopos diferentes ou não publicava, ou mandava o documento da Beta para quem só enxerga a Alfa. E um membro da controladoria delegava o passo de controle, com delegação de escopo nulo, a um colega com act:approvals que não era do papel — ou o reatribuía a ele. E, se o pertencimento fosse exigido só de quem chega por delegação, o membro retirado da controladoria que mantivesse act:approvals decidiria a tarefa ativada antes da retirada, e a rodada nova herdaria a decisão dele. Agora quem não é elegível não recebe nem decide, o quórum incompleto é completado pelo reserva ou para com alerta, o filtro de empresa é por pessoa, e passo de controle só vai a — e só é decidido por — quem é hoje do alvo do nível.

POST /approvals e a reavaliação recebem excludedUsers: pares (userId, reason) com reason = Requester · PreparedBy · Beneficiary · LastEditor · Proponent · RateOverrider · IdentityCorrectionLinked. O módulo dono é obrigado a mandar todos os papéis que o documento tem: o requisitante sempre; quem preparou "em nome de", quando diferente; o beneficiário, quando o documento declara um; o último editor do assunto; na alteração bancária, o proponente; na correção de identidade de fornecedor aprovado (identityCorrection), quem a pediu, como Requester; na proposta de conta ou de canal de aviso de fornecedor que tenha correção de identidade pedida ou decidida, todos os usuários de cada chave de pessoa ligada, como IdentityCorrectionLinked — a lista é montada por chave de pessoa, nunca por usuário, e vale enquanto o fornecedor existir; quem é ligado, o alcance da ligação e a chave de pessoa são regra do Fornecedor (RN-FOR-41), que esta página cita e não redefine; e, da conversão, os dois autores que a Moeda nomeia — o capturedBy de toda taxa do tenant usada e o overriddenBy de quem registrou o exchangeRateOverride, com taxa informada ou só com o tipo —, com ou sem a flag exchangeRateOverridden (RN-AP-70). Lista sem Requester, sem Proponent no BANK_ACCOUNT_CHANGE, ou com usuário de outro tenant é APPROVAL_EXCLUDED_USERS_UNPROCESSABLE · 422, na submissão. Excluir não afrouxa nem devolve: se, depois da exclusão, não sobram elegíveis para o modo, vale a RN-AP-59 — no BANK_ACCOUNT_CHANGE, que não tem reserva, a instância fica parada com alerta já na submissão, com awaitingEligibleApprovers, aviso ao administrador do tenant e à controladoria, e a proposta não volta a quem propôs (RN-AP-61). A tarefa nunca é atribuída a quem o desfecho recusaria. Flag exchangeRateOverridden sem RateOverrider não é recusa: toda taxa que a levanta tem autor, e a Moeda o informa (RN-AP-70).

A lista vive em ApprovalRequestExcludedUser, filha da instância, e só cresce: cada reavaliação acrescenta o editor, ninguém sai. O motor trata cada excluído como o requisitante da RN-AP-08 — removido antes de qualquer regra, em qualquer passo, delegação, reatribuição, escalonamento e reserva — e a decisão repete a checagem (RN-AP-56).

Conflito de perfis. Cada módulo dono declara a permissão de propor o assunto do seu processo; o /validate acusa, como aviso, papel que concede ao mesmo tempo essa permissão e a permissão do nível. É aviso e não recusa porque a exclusão por pessoa já impede o ato; o aviso existe para a auditoria de perfis.

Caso de ataque. O gerente prepara a requisição "em nome de" um analista e depois a aprova como responsável do centro de custo; ou quem editou o pedido já aprovado, subindo o valor, aprova a reavaliação. E, sem a razão da ligação, quem pediu ou decidiu a correção de identidade do fornecedor recebia a tarefa da proposta de conta — ou de canal — daquele mesmo fornecedor: o desfecho recusava com o código do Fornecedor, a decisão não era gravada, a tarefa continuava ativa e ninguém era avisado — laço, não parada. Agora preparador e último editor estão na lista que o módulo manda, as pessoas ligadas entram por chave de pessoa, e o motor os remove de toda tarefa como remove o requisitante.

Processo sem valor. Base semeada: um nível PermissionHolder(approve:supplier-banks) · Quorum(2) · Document. Complementares semeadas, Role(Controladoria) · Any · Document, uma por flag que o Fornecedor calcula: titular ≠ fornecedor — só em fornecedor Foreign, porque nos demais tipos titular diferente é recusado no Fornecedor antes da submissão —, noTrustedPhone, previousNoticeUndeliverable e contestedChannel (tabela de §Processos). Pessoas distintas e diferentes do proponente (RN-AP-56, RN-AP-60). Todo decisor da instância — o quórum e as complementares, a da controladoria inclusive — precisa de identidade verificada e é comparado por CPF: os CPFs são distintos entre si e diferentes do CPF do proponente e das pessoas ligadas ao número do callback; e quem está ligado, sem prazo, a uma correção de identidade daquele fornecedor não decide — nem em proposta de conta, nem em proposta de canal de aviso: o Fornecedor manda, na submissão, todos os usuários de cada chave de pessoa ligada em excludedUsers, com reason = IdentityCorrectionLinked (RN-AP-60), e o motor os remove de toda tarefa antes de qualquer outra regra. As regras são do Fornecedor (RN-FOR-36 e RN-FOR-41), que o Fluxo cita e não redefine, e o desfecho as confere. Travado pelo produto: sem reserva, sem devolução, deduplicateConsecutive, allowReassign, allowEscalation e delegable falsos — PUT que tente mudar é APPROVAL_PROCESS_CONTROL_LOCKED_CONFLICT · 409. Verificado na publicação: o nível Quorum(n) da base é sempre PermissionHolder(approve:supplier-banks) — Role, ApprovalGroup e SpecificUser na base são APPROVAL_LEVEL_NOT_ADMITTED_UNPROCESSABLE · 422, porque trocar o alvo por um papel que dois administradores montam é esvaziar o quórum sem mexer no número —; reserva na política é APPROVAL_POLICY_FALLBACK_NOT_ALLOWED_UNPROCESSABLE · 422; e as quatro complementares semeadas pelo produto não são aposentadas nem alteradas: APPROVAL_POLICY_SEEDED_CONTROL_LOCKED_CONFLICT · 409. O tenant pode acrescentar complementares (Tesouraria para chave PIX não verificada) e endurecer a base (Quorum(3)); nunca publicar base sem Quorum(n) com n ≥ 2 (RN-AP-54). O Fornecedor cita esta definição e não a redeclara.

Janela de aviso. A submissão chega com activationNotBefore = envio do aviso + janela mínima, calculado pelo Fornecedor (RN-FOR-23), e nenhuma tarefa ativa antes (RN-AP-63). O aviso automático sai só por e-mail — não há SMS nem WhatsApp como canal —, e e-mail devolvido não inicia a janela: enquanto nenhum passo ativou, o Fornecedor adia a data pela rota da RN-AP-63; se a devolução chega com as tarefas já ativas, a guarda é do desfecho do Fornecedor.

Proposta imutável, sem devolução. O BANK_ACCOUNT_CHANGE só aprova ou rejeita: return é APPROVAL_RETURN_NOT_ALLOWED_UNPROCESSABLE · 422, não há reatribuição, e os dados da proposta não mudam depois de submetida. Corrigir é rejeitar e abrir proposta nova — instância nova, aviso novo, callback novo, carência nova. Por isso não há rodada nova nem herança de decisão neste processo.

Callback obrigatório, salvo noTrustedPhone — e aí controladoria e comprovante no lugar dele. A evidência é do Fornecedor, que é quem sabe de onde veio o telefone e quem pode registrar a ligação: telefone confiável, separação de pessoas e amarração ao hash dos dados da proposta são a regra dele (RN-FOR-29), e o Fluxo só a cita; na proposta de conta, a titularidade da conta nova é comprovada antes da submissão (RN-FOR-35). A tarefa mostra a evidência ao lado do diff. O motor não a guarda nem a redeclara: a decisão que concluiria a instância invoca o contrato de desfecho, e sem callback Confirmed o Fornecedor devolve Refused(BANK_CHANGE_CALLBACK_REQUIRED_CONFLICT) — a decisão não é gravada e a tarefa continua ativa. Callback Denied é contestação (RN-FOR-30). A exceção tem nome: noTrustedPhone, e vale nos dois casos do processo. Quando o Fornecedor a calcula na submissão, o callback não é exigido e a complementar semeada põe a controladoria na cadeia, sempre com o comprovante que o Fornecedor exige antes da submissão: na proposta de conta, a titularidade da conta nova (RN-FOR-35); na mudança de contato de aviso ou da cadeia, o anexo do tipo declarado que o Fornecedor exige na RN-FOR-40 — o pedido de troca assinado pelo fornecedor, existente, com veredito do antivírus Available — e a carência de 7 dias antes de o contato novo valer (RN-FOR-34). O que o Fornecedor exige é o anexo e o rastro, não a conferência do documento: não há exigência de ICP-Brasil nem de firma reconhecida, e Foreign segue exatamente este caminho. Nunca controladoria sem comprovante, nem comprovante sem controladoria. Com previousNoticeUndeliverable, o callback volta a ser exigido sem essa alternativa, e a controladoria também entra (RN-FOR-23). Com contestedChannel — o Fornecedor travou as propostas de conta por contestação de mudança de contato já aplicada (RN-FOR-38) —, a troca de canal que desbloqueia, e também a mudança de contato da cadeia enquanto a trava durar, abre esta instância com a controladoria na cadeia; o desfecho que a aplica limpa a trava. Consentimento do contato não é condição: é prevenção a fraude.

Contestação. O contato anterior contesta pelo canal que o Fornecedor oferece — link de uso único, sem login. Com a instância em aprovação, o Fornecedor chama POST /approvals/{id}/cancel, que vale em InApproval: a instância termina Cancelled com o motivo da contestação, o desfecho não aplica nada, e trocar a conta exige proposta nova. Depois de aprovada, a contestação segue a regra única do Fornecedor (RN-FOR-30), que vale até 30 dias depois de usableFrom. Quando a proposta contestada trazia contestedChannel ou o anexo do pedido de troca de canal, a contestação suspende o efeito e o caso vai ao complementar da controladoria, que decide com a evidência — não reverte sozinha ao valor anterior —, e a instância chega ao motor com a flag; e a contestação feita por dentro do Nexio, por quem tem read:supplier-banks, exige segunda pessoa, como todo ato de controle. As duas regras são do Fornecedor, e esta página as cita.

Caso de ataque. Se o processo avaliasse valor, todo fornecedor sem compras avaliaria zero, a política por faixa nunca casaria e a troca cairia num Any de uma assinatura; com dedupe, o quórum seria pulado; um administrador trocaria o modo; o aviso iria ao e-mail que a fraude pressupõe comprometido, e o fornecedor legítimo não teria por onde dizer "não fui eu". Aqui não há faixa a contornar, o quórum de duas pessoas é verificado na publicação e na decisão, a configuração está travada, a troca não conclui sem callback confirmado para telefone confiável — ou, com noTrustedPhone, sem controladoria e sem o anexo comprobatório que o Fornecedor exige e grava —, a contestação encerra a instância, e a troca de canal que desbloqueia fornecedor contestado passa pela controladoria.

O módulo dono pode devolver o valor avaliado como indisponível — cálculo que depende de módulo que ainda não existe, fornecedor sem histórico —, e nunca como zero. A instância grava valueUnavailable e valor nulo. Na submissão: critério faixa de valor não casa; activationMinValue não pula o nível — o nível entra; e cadeia que precisa comparar alçada ou materialidade é recusada com APPROVAL_VALUE_UNAVAILABLE_UNPROCESSABLE · 422, porque não há com o que comparar.

Caso de ataque. "Fornecedor novo avalia zero" fazia de zero um valor legítimo, e activationMinValue de R$ 0,01 desligava todos os níveis. Agora indisponível não é zero, não casa faixa e não desliga nível: o erro de cálculo cai sempre para o lado de mais controle.

POST /approvals aceita activationNotBefore ou activationHeld. Com data, nenhum passo ativa antes dela: o mesmo relógio do motor que vence SLA ativa o primeiro passo na hora, como ação de sistema (actorUserId nulo), com o tenant gravado no próprio agendamento. Com activationHeld, a instância espera o módulo dono informar a data. POST /approvals/{id}/activation-window (interna) fixa ou adia a data; antecipar, ou mexer depois que um passo ativou, é APPROVAL_ACTIVATION_WINDOW_UNPROCESSABLE · 422. Antes da ativação não há tarefa, logo não há decisão possível. O SLA do primeiro passo conta da ativação. Consumidor na v1: a alteração bancária (RN-AP-61).

Caso de ataque. A janela mínima entre o aviso ao fornecedor e a decisão pedia uma ativação adiada que o motor não tinha: disparar o aviso e aprovar no mesmo minuto só documentava a fraude. Agora não existe tarefa antes da data, e a data só anda para frente.

Passo de controle é, e só é: (a) todo passo de nível de política complementar; (b) o passo de controladoria criado pela RN-AP-58 (controlOfStepId preenchido); (c) o passo Quorum da base do BANK_ACCOUNT_CHANGE (RN-AP-61). Nunca se reconhece pelo nome do papel: um nível Role(Controladoria) numa política base é passo comum, e uma complementar SpecificUser(CISO) é passo de controle. A condição é derivada na criação do passo, da política e do processo congelados (RN-AP-06) — nenhuma configuração do tenant a liga ou desliga. O passo marcado authorityExceeded não é passo de controle: o controle dele é o passo de controladoria, que nasce na ativação do marcado mesmo que a dedupe o leve a Skipped.

Invariante do agregado, verificada na decisão, dentro da transação da RN-AP-44: a mesma pessoa não decide um passo de controle e qualquer outro passo da rodada corrente — da base ou de controle —, contadas as decisões herdadas, em qualquer ordem. Violação é APPROVAL_CONTROL_STEP_SAME_PERSON_FORBIDDEN · 403.

Na ativação, quem já decidiu passo da rodada sai das tarefas do passo de controle, e quem já decidiu passo de controle sai das tarefas de todo outro passo — de base ou de controle —, que continua com os demais e nunca vai a Skipped por essa decisão; a dedupe nunca pula passo de controle nem conta decisão de controle como cobertura (RN-AP-57); delegação, reatribuição e escalonamento de passo de controle só alcançam quem pertence ao alvo do nível e não decidiu outro passo da rodada, e o próprio titular só decide enquanto pertencer a ele (RN-AP-59 (2)). Se ninguém sobra, vale a RN-AP-59 — o passo para com alerta, e o reserva nunca controla o que ele mesmo produziu (RN-AP-58). Consequência aceita: tenant pequeno precisa de mais uma pessoa para cada controle.

Caso de ataque. Se o controle fosse reconhecido pelo nome do papel, a complementar "estado do orçamento = Exceeded" com nível Role(Controller) · Any não seria controle; o Owner que aprovou a fatia no degrau anterior, sendo também desse papel, teria o passo levado a Skipped pela dedupe — quem aprovou a base passaria pelo controle da verba. E a gestora da raiz, sendo da controladoria, aprovaria o passo de controladoria que a própria marca criou. E, se a regra valesse só num sentido, quem decidiu a complementar poderia ter a decisão contada como cobertura do passo comum seguinte. Agora toda complementar é passo de controle, seja qual for o papel, e vale nos dois sentidos: a pessoa sai das tarefas dele, a segunda decisão da mesma pessoa é recusada com 403, e o controle só fecha com outra pessoa.

Todo ApprovalLevel tem stage, obrigatório, e dentro da política ele cresce estritamente com order — verificado na publicação (APPROVAL_LEVEL_STAGE_UNPROCESSABLE · 422). Na resolução, os níveis da base vencedora e das complementares que casaram são ordenados por stage; níveis com o mesmo stage formam um degrau: seus passos ativam juntos, em paralelo, e o degrau seguinte só ativa quando todos fecham. priority decide só qual base vence; isDefault só responde quando nenhuma outra base casa. "Passo anterior", para a dedupe, é o degrau anterior.

Caso de ataque. Com a posição dada pela prioridade da complementar e o order local da base, nada dizia se o controller do estouro de verba vinha antes ou depois do comitê, nem o que fazer com duas complementares de mesma prioridade — cada implementação intercalaria de um jeito, e a dedupe pularia degraus diferentes. Agora a ordem é um número publicado e o empate é paralelo, por regra.

Os critérios têm alcance de documento, de linha ou de fatia (ver Critérios disponíveis). A política casa quando o documento satisfaz os de documento e existe uma linha que satisfaz sozinha todos os de linha — e, havendo critério de fatia, uma fatia dessa linha que satisfaz todos. O escopo Line gera passo para cada linha que satisfaz os critérios de linha da política de origem do nível. Verificado na submissão, na reavaliação e na simulação; não tem erro próprio.

Caso de ataque. Uma linha de software sem dado pessoal somada a uma de hardware com dado pessoal acionava "software com dado pessoal", e na escolha da base podia vencer uma de menos controle só porque critérios de linhas diferentes se juntaram. Agora cada linha responde por si.

Toda decisão grava subjectVersion e subjectHash do conteúdo aprovável do documento, e no metadata os anexos vistos (fileId e sha256) e, onde a separação é por pessoa — passo de controle, BANK_ACCOUNT_CHANGE e correção de identidade do fornecedor —, o CPF verificado de quem decidiu e o estado da identidade no momento da decisão, para que o desfecho compare pessoas sem depender de o CPF ainda estar lá quando ele conferir; que o CPF verificado não mude depois de gravado é requisito da demanda de plataforma (P17). A abertura de cada rodada grava o mesmo par; approval-step.activated grava as pessoas resolvidas e a origem de cada uma. O módulo dono calcula e manda versão e hash em POST /approvals, no reenvio e na reavaliação — submissão sem eles é APPROVAL_SUBJECT_HASH_REQUIRED_UNPROCESSABLE · 422. Revogar anexo depois não muda o que foi visto: o hash fica.

Caso de ataque. Sem versão nem hash do assunto, não se provava qual versão do documento foi aprovada, e sem as pessoas resolvidas a reexecução "exata" dependia de papéis que o GrydAuth não versiona. Agora a trilha responde "esta versão, com estes anexos, por quem estava habilitado naquele dia".

Quando o PURCHASE_ORDER cita a instância aprovada da REQUISITION de origem, os níveis da política base nascem Skipped, com o motivo e a instância de origem no evento, só se as duas condições valem: (a) centro de custo, conta contábil e categoria de cada fatia são os aprovados; (b) a soma das fatias de todos os pedidos que citam a instância — os já submetidos, mais este —, agregada por (centro de custo, conta contábil, categoria), é menor ou igual ao aprovado para a mesma tupla, na moeda funcional em que a alçada foi avaliada. Cada pedido entra pelo valor das fatias menos o cancelado: o rejeitado não entra; o cancelado, total ou parcialmente, fica na soma pela parte que não foi cancelada — a recebida ou aceita antes do cancelamento — e nunca sai inteiro. As complementares rodam sempre: fornecedor sancionado, UF de entrega e estado do orçamento só existem de verdade no pedido. Fora dessas condições, a cadeia roda inteira. Pedido que cita mais de uma requisição, ou cuja instância de origem não está mais em Approved — requisição reaberta, por exemplo —, roda a cadeia inteira; a dispensa para N origens é decisão da spec do Pedido.

Onde e sob qual trava. Verificado na submissão, na reavaliação e no reenvio do pedido, sempre com o valor novo das fatias e sob a trava da instância de origem: cada um desses atos incrementa a version da ApprovalRequest da requisição na mesma transação (RN-AP-44), de modo que dois atos concorrentes não leem a mesma soma — o segundo relê e soma o primeiro. Se a soma estoura, a dispensa cai: a base volta a ser exigida, a cadeia recalculada deixa de ser subconjunto da anterior e a rodada recomeça do zero (RN-AP-21). O pedido que não mudou continua com a dispensa que já tinha; quem estoura a soma é o pedido que mudou. A soma pressupõe que o valor de um pedido nunca fica abaixo do recebido ou aceito nele — requisito da spec do Pedido. Só o pedido rejeitado sai inteiro da soma; cancelar libera só a parte cancelada, e o pedido seguinte cabe só nela. Os campos do contrato — entre eles o valor cancelado por fatia — nascem com a spec do Pedido.

Caso de ataque. "Não precisar de nova cadeia" deixava um pedido para fornecedor sancionado, ou com a UF de entrega trocada, passar sem o compliance e sem o fiscal. E, se cada pedido fosse comparado sozinho com o aprovado, dois pedidos de R$ 100 mil citando a mesma requisição de R$ 100 mil dispensariam a base duas vezes — R$ 200 mil com uma alçada de R$ 100 mil. E, se o pedido cancelado saísse inteiro da soma, na mesma requisição um primeiro pedido de R$ 100 mil recebido em R$ 60 mil e cancelado no resto deixaria o segundo, de R$ 100 mil, somar R$ 100 mil e dispensar a base de novo — R$ 160 mil comprados com uma alçada de R$ 100 mil. Com a parte recebida na soma, o segundo pedido de R$ 100 mil soma R$ 160 mil e roda a cadeia inteira, e só um segundo pedido de até R$ 40 mil dispensa. E, se a soma fosse conferida só na submissão, na mesma requisição de R$ 100 mil dois pedidos de R$ 50 mil com a base dispensada deixariam o primeiro ser editado para R$ 100 mil e reavaliado ainda sem a base — R$ 150 mil com uma alçada de R$ 100 mil. Com a soma de novo na reavaliação, o pedido editado soma R$ 150 mil e roda a cadeia inteira. Agora só a alçada já assinada é dispensada, só até o valor que ela assinou, e só se nada que ela leu mudou.

São parâmetros críticos, e só estes: em ApprovalSettings, allocationMaterialityPercent e allocationMaterialityAmount; em ApprovalProcessSettings, fallbackApproverType · fallbackApproverRef, authorityExceededBehavior, deduplicateConsecutive e delegable; os membros — entrada, saída e vigência — de ApprovalGroup usado como reserva de processo ou de política, ou referenciado por nível de controle em política ativa ou na cadeia congelada de instância viva (RN-AP-64: nível de complementar, passo de controladoria, quórum do BANK_ACCOUNT_CHANGE); e os membros do papel funcional Controladoria e de todo papel referenciado por nível de controle em política ativa ou na cadeia congelada de instância viva. Instância viva, aqui, é a que está em InApproval: ela fica na versão de política que a formou (RN-AP-05) e lê os membros quando o passo ativa e de novo na decisão (RN-AP-07, RN-AP-59), então o grupo ou papel que só uma versão aposentada usa continua decidindo controle até a última instância dessa versão terminar. O reserva declarado na política já segue a RN-AP-55. A condição do grupo é lida na transação da mudança, contra as políticas publicadas e as cadeias congeladas das instâncias em InApproval, sob a trava por (tenant, processo) de todo processo com versão de política — ativa ou aposentada — que referencie o grupo, a mesma da publicação (princípio 3); a submissão toma essa trava em modo compartilhado, para que nenhuma instância se forme com uma versão que a mudança não viu. Grupo que passa a ser referenciado por nível de controle entra na regra pela publicação da política, que já exige segunda pessoa, e o diff dela mostra os membros vigentes do grupo (RN-AP-55).

A mecânica. PUT /approval-settings, PUT /approval-processes/{id} e a edição de grupo não alteram parâmetro crítico: corpo que muda um deles é APPROVAL_SETTINGS_CRITICAL_FIELD_CONFLICT · 409, e as travas do BANK_ACCOUNT_CHANGE continuam respondendo antes (RN-AP-54). A mudança nasce como ApprovalSettingsChange Pending pela rota de proposta do alvo, com o diff campo a campo — valor vigente e valor novo — e proposedByUserId; a proposta nunca é editada: mudar é descartar e propor de novo. Efetiva por …/apply, que grava o valor novo na mesma transação, por pessoa com a permissão do alvo, diferente de quem propôs e fora de quem a mudança beneficia — os membros que ela inclui num grupo ou cuja vigência prorroga, e o usuário, ou os membros do grupo, que ela põe como reserva. Qualquer dos dois casos é APPROVAL_SETTINGS_CHANGE_SELF_APPLY_FORBIDDEN · 403, e nada é gravado. A remoção tem guarda própria. Quem propõe e quem efetiva a saída de membro — ou o encerramento da vigência dele — de grupo ou papel referenciado por nível de controle, ou de grupo usado como reserva de processo ou de política, não pode ser membro remanescente desse grupo ou papel depois da mudança: é APPROVAL_SETTINGS_CHANGE_CONTROL_MEMBER_REMOVAL_FORBIDDEN · 403, conferido na proposta e de novo na efetivação, e nada é gravado. E a redundância tem piso. A remoção que deixa menos de dois membros vigentes em grupo referenciado por nível de controle cujo modo é Any responde o mesmo 403, seja quem for quem propõe e quem efetiva: é a redundância que a regra protege, e um Any de uma pessoa só fecha o controle com uma assinatura. O piso é do grupo, não da reserva declarada como pessoa (fallbackApproverType = User), que é de uma só por desenho. Onde a comparação desta cláusula é por CPF, esta também é. Sem ela, a guarda do beneficiário não alcança quem esvazia o grupo de fora: quem remove não é incluído, prorrogado nem posto como reserva, e duas pessoas de fora do grupo tiram os demais e deixam um membro único decidindo — ou um membro efetiva a proposta do colega que tira os outros e fica sozinho no Any do controle. Onde há nível de controle, a comparação é por pessoa, não por usuário. Onde a mudança toca grupo ou papel referenciado por nível de controle (RN-AP-64), quem propõe, quem efetiva e quem a mudança inclui num grupo ou cuja vigência prorroga precisam de identidade verificada, com CPF único por tenant — a mesma do Fornecedor (RN-FOR-36), que esta página cita e não redefine —; sem ela, a proposta e a efetivação respondem APPROVAL_SETTINGS_CHANGE_IDENTITY_NOT_VERIFIED_CONFLICT · 409, e nada é gravado. E "quem propõe ≠ quem efetiva ≠ quem é incluído" é conferido por CPF, nunca por userId: efetivar com o CPF de quem propôs, ou com o CPF de quem a mudança inclui ou prorroga, é o mesmo APPROVAL_SETTINGS_CHANGE_SELF_APPLY_FORBIDDEN · 403. O alcance da identidade verificada — membro de grupo e de papel de controle, e quem efetiva — é requisito da demanda de plataforma (P17). Fora daí, a comparação é por userId. Nos demais parâmetros críticos — allocationMaterialityPercent e allocationMaterialityAmount, fallbackApproverType e fallbackApproverRef, authorityExceededBehavior, deduplicateConsecutive e delegable —, "quem propõe ≠ quem efetiva" é conferido por userId e não se exige identidade verificada. Risco aceito e registrado: a mesma pessoa, com dois usuários, propõe e efetiva mudança de materialidade ou de alçada. O que fica contra ele: a dupla custódia por usuário, o ato registrado com quem propôs, quem efetivou e o diff campo a campo, o aviso obrigatório à controladoria depois do commit (approval-settings-change.applied) e o fato de a mudança não alcançar instância aberta — o que a cadeia congelou não muda (RN-AP-06). Não se promete mais do que isso. A dupla custódia da eliminação de anexo, que é do Anexo, continua sendo por usuário, e esta regra não a alcança. Se a proposta não está Pending ou o valor vigente não é mais o "antes" dela, APPROVAL_SETTINGS_CHANGE_STALE_CONFLICT · 409. …/discard encerra sem efeito. O que a cadeia congelou não muda (RN-AP-06); os membros do grupo, que a ativação e a decisão leem, mudam — e é por isso que o grupo da cadeia congelada está na regra.

A prova e o aviso. É ato de controle: a ApprovalSettingsChange guarda alvo, diff, quem propôs, quem efetivou ou descartou e quando, isolada pelo tenant, e não sofre escrita além da transição de status (Pending · Applied · Discarded). Depois do commit sai approval-settings-change.applied, e a controladoria recebe aviso obrigatório com o diff.

Os membros de papel vivem no GrydAuth. O Nexio não intercepta concessão de papel: para o papel Controladoria e todo papel referenciado por nível de controle em política ativa ou na cadeia congelada de instância viva, o evento de concessão e retirada com quem concedeu (P16) e a segunda pessoa, com recusa de conceder a si mesmo (P-T5-4), são requisito da demanda de plataforma. Quando o evento existir, o Nexio o consome e avisa a controladoria; até lá, a regra está declarada e não é verificável pelo motor, e isso bloqueia o primeiro tenant em produção.

Caso de ataque. Com a política sob duas pessoas, o mesmo administrador subia a materialidade para 40% e a fatia que exigiria o diretor era absorvida pela maior; ou apontava a si mesmo como reserva do processo, ou se incluía no grupo de reserva ou no grupo que decide a complementar de fornecedor sancionado, ou ligava a delegação no processo que a controladoria tinha fechado — o controle da RN-AP-55 contornado pela configuração ao lado, sem diff e sem aviso. Agora cada um desses parâmetros só muda com uma segunda pessoa e chega à controladoria com o diff. Duas brechas vizinhas fechariam o controle por outro lado: a versão nova da complementar de fornecedor sancionado troca o grupo por um Role, o administrador se inclui no grupo antigo — que nenhuma política ativa usa mais — e decide o controle do pedido formado na versão anterior; ou A propõe incluir C no grupo de controle, e o próprio C efetiva. Com o grupo da cadeia congelada na regra enquanto houver instância em InApproval, e com quem é incluído fora de quem efetiva, as duas pedem uma terceira pessoa. E a mesma porta existia pela reserva: com A, B e C no grupo de reserva do processo, D propunha tirar B e C e E efetivava — nenhum dos dois membro, nenhum dos dois incluído ou prorrogado —, e A virava aprovador de reserva único de todo passo parado. Agora o grupo de reserva está na cláusula da remoção, e o grupo de controle em Any não desce de dois membros, seja quem for quem propõe e quem efetiva. E, enquanto a comparação era por userId, C efetivava a própria inclusão pelo segundo usuário dele — a mesma pessoa, dois logins: por CPF verificado os dois são um só, e a efetivação é recusada.

Nos processos com valor, o tipo de taxa da conversão vem da configuração por processo — processRateTypes, uma entrada por processo com valor, na Moeda, que é a página dona do nome; o defaultRateType vale só para o movimento sem documento de origem —; quem pede, prepara ou submete não o escolhe. Documento convertido com exchangeRateOverride — taxa informada, ou de outro tipo, por quem tem a permissão de informar taxa no documento —, ou cuja taxa usada é do tenant e tem como autor (capturedBy) alguém entre os demais excluídos da RN-AP-60 ou quem submete, chega com a flag exchangeRateOverridden — derivada pela Moeda e calculada pelo módulo dono na submissão e na reavaliação, nunca declarada por quem pede. E o autor de toda taxa do tenant usada, com ou sem a flag, entra em excludedUsers com a razão RateOverrider, como quem informou a taxa no documento (RN-AP-60). As duas regras são da Moeda (RN-CUR-27); o Fluxo as cita com esses nomes. A complementar semeada Role(Controladoria) · Any · Document casa pela flag, é passo de controle (RN-AP-64) e é travada (APPROVAL_POLICY_SEEDED_CONTROL_LOCKED_CONFLICT · 409): decide pessoa distinta do requisitante e do autor da taxa; e o autor de taxa do tenant usada não decide nenhum passo da instância, com ou sem a complementar. A flag nunca chega sem a razão na lista. Mesmo no exchangeRateOverride só de tipo — sem rate informada — há RateOverrider: a Moeda preenche o capturedBy com o autor da linha de taxa efetivamente usada e o overriddenBy com quem registrou o override, e os dois entram em excludedUsers com essa razão — é o que impede que quem acionou a complementar seja quem a decide. Por isso flag sem RateOverrider não é recusa na submissão (RN-AP-60). Na submissão e na reavaliação — que é onde a flag pode nascer de novo — sai nexio.approval-request.exchange-rate-overridden à controladoria. A flag está no retrato (RN-AP-21): informar ou trocar a taxa depois de aprovado abre rodada nova. Que a taxa informada nunca vira taxa do tenant é regra da Moeda.

Caso de ataque. A taxa decide a alçada: num pedido de US$ 100 mil, o comprador informa 4,20 em vez de 5,40, o valor convertido cai de R$ 540 mil para R$ 420 mil, abaixo da faixa do diretor, e ninguém revê a taxa. E, se só a taxa informada contasse, o comprador gravaria antes uma taxa Manual de 4,20 no tenant e submeteria com ela; se escolhesse o tipo, submeteria com uma Contracted antiga, gravada para outro fim; e, se a exclusão olhasse só quem move o documento, um aprovador com create:exchange-rates gravaria a taxa baixa e decidiria o pedido do colega que caiu na alçada dele. Agora o tipo é da configuração, a taxa informada ou de outro tipo — ou a do tenant gravada por quem move o documento — põe a controladoria na cadeia, e o autor de toda taxa usada não decide nenhum passo.

Há dois caminhos em que nenhuma pessoa decide, e nos dois o contrato de desfecho do ApprovalProcessCode é invocado na transação do ato que os provoca, como na decisão humana (RN-AP-38).

Aprovação pela política (RN-AP-32), na transação do POST /approvals. Applied: a instância nasce Approved, grava approval-request.approved-by-policy e o módulo dono aplica o efeito — a requisição grava o Commitment. Refused(code): o envio é recusado — a instância não nasce, nada é gravado, e o POST /approvals responde com o código do módulo, sem reembrulho; o documento continua em rascunho para quem enviou corrigir e enviar de novo. Não há tarefa a manter ativa, porque não há aprovador, e Returned não serve: diria que alguém devolveu.

Ajuste do documento aprovado. A alteração em que valem as condições (a), (b) e (c) da RN-AP-21 — valor do documento, de cada fatia e de cada linha que não subiu, retrato de critérios igual (o criteriaSnapshotHash não mudou) e cadeia recalculada igual ou contida — não reabre: na transação do POST /approvals/{id}/revaluate a instância continua Approved, sem rodada nova, sem tarefa e sem mexer no roundNumber, grava approval-request.revaluated com o que mudou e a subjectVersion/subjectHash novas, e invoca o contrato de desfecho como ajuste. Applied: o módulo dono aplica o efeito da diferença — a requisição grava no razão só a diferença da parte ainda não pedida (Orçamento, RN-O45). Refused(code): a alteração é recusada — nada é gravado, o documento continua na versão aprovada, a tentativa fica registrada em transação própria como approval-request.decision-refused, o revaluate responde com o código do módulo, e requisitante e dono do impedimento são avisados. Alteração de taxa — incluir, trocar ou remover o exchangeRateOverride, ou trocar a moeda do documento — nunca é ajuste (RN-AP-70). O teste de ajuste roda pela taxa já gravada no documento, e o ajuste grava a diferença por ela; só a rodada do zero, já decidida, reconverte o documento com a data do ato (Moeda e Câmbio, RN-CUR-22) — assim o câmbio do dia nunca faz de uma reabertura um ajuste. Quem reconverte é o módulo dono, no desfecho da reabertura, que devolve a conversão nova ao motor (RN-AP-72). No BANK_ACCOUNT_CHANGE o revaluate continua recusado (RN-AP-61). Fora de (a), (b) e (c), a alteração reabre (RN-AP-43) e a rodada é do zero, com as tarefas criadas como na submissão; a última aprovação humana chama o desfecho, que grava a diferença.

Failed, nos dois caminhos: rollback total, como na RN-AP-38. No ajuste, quem decidiu continua valendo mesmo que hoje não passasse na RN-AP-59: a assinatura era válida quando foi dada, e o ajuste não pede assinatura nova.

Por quê: sem esta regra, a aprovação pela política terminava Approved sem desfecho — requisição aprovada sem Commitment —, e a alteração em que todos os passos herdavam deixava a instância em InApproval sem tarefa e sem transição que a levasse a Approved, com a diferença de verba sem ninguém para gravá-la. Nos dois caminhos quem age é o requisitante, e é a ele que a recusa volta: é quem pode corrigir a data, pedir remanejamento ou esperar a verba.

POST /approvals, :simulate, :preview, /resubmit e /revaluate recebem o corpo de §Contrato de submissão — envelope, linhas, fatias, conversão, flags e excluídos. O módulo dono monta o corpo e converte pela Moeda (Moeda e Câmbio, RN-CUR-22); o motor não lê tabela do dono para casar critério. É recusado com APPROVAL_SUBMISSION_CONTRACT_UNPROCESSABLE · 422, nomeando o campo e a linha: campo que o processo exige ausente, ou que ele não admite presente; lineId ou allocationId repetido; soma das fatias diferente da linha, na moeda do documento ou na funcional; conversion ausente com moeda diferente da funcional, ou presente com a mesma; empresa que não é a do estabelecimento; flag fora das que o processo declara; valor negativo. Verificado na submissão, no reenvio, na reavaliação, na simulação e na prévia.

O que o motor calcula, ele não recebe: o path dos nós, resolvido pelo contrato de cada dono e congelado no retrato; o valor avaliado dos processos com linhas, soma dos functionalAmount; o limiar de materialidade (RN-AP-15); o sinal de orçamento de cada fatia (RN-AP-27); e a cadeia.

O retrato e o hash. O criteriaSnapshot é o corpo sem os excluídos, a versão, o hash do assunto e a ativação, com os path resolvidos e o sinal de orçamento de cada fatia. O criteriaSnapshotHash cobre os atributos — empresa, estabelecimento, moeda, flags do assunto e, por linha e por fatia, tudo o que os critérios leem, com o sinal de orçamento — e não cobre valores nem a taxa: valor é a condição (a) da RN-AP-21, e atributo é a (b). Com o valor dentro do hash, toda redução de valor mudaria o retrato, e o ajuste da RN-AP-71 só existiria para edição que não mexe em número. Linha ou fatia que entra ou sai muda o hash. Linhas ordenadas por lineId e fatias por allocationId antes de calcular: a ordem de envio não muda o hash.

Reabertura e taxa. No revaluate o corpo vem pela taxa gravada: conversion tem de ser a da instância, e o teste de ajuste roda sobre ele (RN-AP-71). Se o motor decide reabrir, quem reconverte é o dono, no desfecho da reabertura (RN-AP-43), com a data do ato: o desfecho devolve Applied com a conversão nova — conversion, o functionalAmount de cada linha e de cada fatia, a flag exchangeRateOverridden e os RateOverrider dela —, e a rodada do zero é montada com esses números. Sem cotação, o desfecho devolve Refused(EXCHANGE_RATE_MISSING_UNPROCESSABLE), o revaluate é recusado e o documento fica onde estava. O reenvio, que é sempre rodada nova, já chega reconvertido. O que a reconversão grava no razão é do Orçamento (RN-O59).

Uma instância viva por assunto e processo. POST /approvals para assunto com instância InApproval ou Returned no mesmo processo — ou Approved, fora da correção de identidade de fornecedor aprovado — é APPROVAL_REQUEST_ALREADY_EXISTS · 409: o aprovado muda por revaluate, e o devolvido volta por resubmit.

Caso de ataque. Sem esquema, a requisição mandaria o total, e a cadeia sairia pelo total — o pedido rateado 90/10 exigiria o diretor da área que ficou com R$ 40 mil —; mandaria categoria e flags juntadas no documento, e "software com dado pessoal" casaria somando duas linhas (RN-AP-66); converteria o total em vez das fatias e criaria o segundo resíduo que a convenção de dinheiro proíbe; e mandaria a taxa do dia na reavaliação, e o câmbio faria de uma reabertura um ajuste. Agora cada linha e cada fatia chegam com a sua identidade e os seus atributos, a conversão é a do documento, e o que o corpo não diz o motor recusa.