Loop de Aprovação do Operador

Um agente que conversa com contrapartes externas nunca deve enviar por conta própria e deve manter o operador informado internamente. Esta habilidade define o contrato: cada rascunho de saída é registrado como uma obrigação, um operador decide o texto exato e um registro de entrega prova o que foi enviado.

Quando Usar

• Um agente redige respostas para clientes, fornecedores, investidores ou parceiros em um canal compartilhado, e-mail ou chat, e um humano deve aprovar antes de enviar.
• Você precisa de uma trilha de auditoria que vincule cada mensagem enviada ao texto exato do rascunho, ao operador que a aprovou e ao tempo da decisão.
• Você viu uma aprovação antiga liberar um rascunho reescrito, ou dois trabalhadores entregarem a mesma mensagem aprovada duas vezes.
• Rascunhos continuam pedindo fatos às contrapartes que o registro já possui.

Como Funciona

Objetos

O esquema de referência está em references/approval-ledger.sql.

Registrando um rascunho

1. Limpe as entradas. Remova caracteres de controle, colapse espaços em branco em campos de linha única e aplique limites de comprimento (rascunho, resumo, contexto, contraparte). Campos vazios ou excessivamente grandes são recusados, não truncados silenciosamente.
2. Execute o portão de linha de base (abaixo). Ele pode recusar o registro.
3. Gere o hash do texto do rascunho com sha256. O prefixo do hash vai para o resumo para que o painel de aprovação mostre qual texto está sendo aprovado.
4. Atualize ou insira. Se já existir uma obrigação redigida em aberto para a mesma (contraparte, canal), substitua a linha auxiliar do rascunho e avance a updated_at da obrigação. Esse avanço é a rotação da época: qualquer decisão vinculada à época antiga não poderá mais liberar o novo texto. Caso contrário, insira uma nova obrigação com o status drafted.
5. Encaminhe o recibo de registro apenas para um destino interno de operações configurado e verificado. Se a origem for esse destino interno, acuse o recebimento lá. Nunca silencioso significa relatórios internos, não uma resposta externa automática. Mantenha hashes de rascunho, status de aprovação, identidade do operador e metadados do fluxo de trabalho fora dos canais visíveis para a contraparte. Origens desconhecidas ou não classificadas permanecem em silêncio; uma mensagem direta não é automaticamente interna.

Se um destino interno verificado não estiver disponível, retenha o resultado do registro no resultado da ferramenta interna ou na superfície do operador. Nunca recorra a uma origem externa ou desconhecida. Um resultado de ferramenta exposto a terceiros não é uma superfície interna.

Registrar um rascunho não autoriza uma resposta externa. Qualquer pergunta esclarecedora permitida pela política ou resposta neutra é uma decisão de saída separada, sujeita às restrições existentes de menção, canal, apenas rascunho, congelado e nunca em counterparty-channel-discipline. Não deve divulgar metadados de aprovação interna.

Portão de linha de base

Antes que qualquer rascunho seja registrado, consulte a linha de base atual para a contraparte (um registro temporal, loja de contratos ou CRM):

• Contrato assinado ou entregue registrado: recuse o registro com a evidência e uma recomendação. Perguntar a uma contraparte sobre especificações após a assinatura é a falha exata que este portão existe para impedir.
• Substituição do operador: force_despite_signed_contract permite que o registro passe e insere [BASELINE_OVERRIDE_SIGNED_CONTRACT] no contexto do rascunho.
• Serviço de portão inacessível: o registro prossegue e o contexto é marcado com [BASELINE_CHECK_UNAVAILABLE]. O painel vê que a proteção estava desativada. Falhas nunca desativam o portão silenciosamente.
• Quando os fatos estiverem disponíveis, anexe os poucos mais recentes ao contexto como um resumo [BASELINE FACTS: ...] para que o rascunho chegue com a verdade atual.

Decidindo

…