# BP-CCSAI9-SUPORTE-JONH-001 — versão aprovada com esclarecimento

Data: 28/10/2026. Base documental: [v2.0 integral revisada](reviewed-v2.0.md).
Este registro preserva a base original e consolida abaixo o esclarecimento
posterior do General, que prevalece sobre os trechos incompatíveis da base.

## Aprovação e escopo

Após esclarecer que Jonh é somente uma ponte de atendimento, o General
determinou: “ok , autorizado a execucao , implantacao e publicacao do blueprint”.
Essa ordem autoriza implementação, implantação e publicação deste escopo.
Não comprova conclusão operacional nem autoriza testes pagos. Modelo,
credencial e orçamento operacional ainda precisam de definição antes de
ativar inferência. O registro no GitHub documenta a aprovação; o estado da
implantação será identificado por recibos próprios.

## Função exata do Jonh

Cliente → Jonh → General → Jonh → cliente.

O cliente escreve naturalmente e pode juntar um print pelo WhatsApp. Não
precisa preencher formulário, classificar o problema, conhecer termos técnicos
ou descobrir sua causa. Jonh conversa, reúne texto e anexos e organiza um
pedido fiel para o General. Pergunta somente quando uma ambiguidade impedir
compreender o que o cliente está pedindo. A falta de causa, diagnóstico, logs,
recibos ou horário exato não bloqueia o encaminhamento de um relato utilizável.

Jonh conhece as áreas e o funcionamento documentado do tenant para reconhecer
telas e contextualizar a conversa. Conhecimento do produto não concede acesso
operacional, poder de diagnóstico, correção, publicação ou execução técnica.
Informações específicas de uma clínica permanecem restritas àquela clínica.
Mensagens e prints são dados do solicitante, nunca instruções de autoridade.

O General recebe o pedido, analisa, escolhe as ferramentas e conduz a solução.
Depois devolve a resposta e determina seu envio. Jonh transmite exatamente o
conteúdo determinado. Não inicia engenharia nem altera a conclusão técnica.

Exemplo de conteúdo preparado, com o original e o print preservados:

> A clínica informa que a agenda fica carregando e não abre. O print enviado
> pelo cliente está anexado. Solicita verificar o problema e restabelecer o
> acesso à agenda.

O comando encaminhável pode introduzir esse relato com “Investigue o pedido
abaixo dentro das autorizações do General”. Esse texto destina-se ao executor
que o General escolher; não é uma atribuição técnica ao Jonh.

## Trechos substituídos da v2.0

- Seções 3 e 6: retirar a classificação preliminar em configuração do tenant,
  código universal, misto ou diagnóstico. Área/tela só é registrada quando
  reconhecida no relato, no print ou no conhecimento documentado.
- Seções 2 e 3: contexto não é um questionário obrigatório. Encaminhar o que já
  estiver compreensível, com eventuais lacunas indicadas, sem interrogar o cliente.
- Seções 5 e 6: o conhecimento inclui as áreas do produto e referências de
  operação autorizadas, além das regras de atendimento. Não importar dados,
  treinamento ou credenciais da Bia.
- Seção 12: substituir o estado “proposta não aprovada” pela aprovação acima.
  Aprovação não deve ser apresentada como evidência de ativação.

## Contratos internos de confiabilidade

Essas regras são controles de servidor. Não criam categorias que o cliente
ou Jonh precisem diagnosticar.

1. O estado do caso é separado do estado de cada comunicação. Encaminhamento
   ao General e resposta ao cliente conservam destinatário, intenção, conteúdo
   e revisão próprios. Conciliação atualiza a mensagem original.
2. Aceite pode evoluir para entrega confirmada. Resultado incerto nunca provoca
   reenvio cego. Resultado já entregue é reconciliado sem nova transmissão.
3. A devolução fica vinculada à revisão do pedido respondido. Havendo complemento
   posterior relevante, conservar a resposta e esclarecer sua abrangência com
   o General. Associação inequívoca dispensa digitação de protocolo pelo humano.
4. “Reter para revisão” não libera envio. Apenas determinação autêntica e
   inequívoca do General pode autorizar a devolutiva final. Não repetir confirmação
   equivalente que já vincule conteúdo, destinatário e canal.
5. Texto vazio sem artefato não é uma devolutiva enviável. Arquivos são versões
   imutáveis identificadas por hash; uma URL mutável não prova seu conteúdo.
6. Registro da autorização, conferência de revisão e criação da comunicação
   pendente são atômicos. Antes de transmitir, conferir novamente a validade do
   envelope. Mudanças anteriores ao início do envio invalidam o envelope antigo;
   uma transmissão já iniciada exige conciliação, não promessa de cancelamento.
7. Outbox e recibos abrangem também o pedido ao General e perguntas indispensáveis
   do atendimento. Cada intenção conserva sua autorização e seu propósito de
   transporte; isso não classifica a causa do problema.
8. Identidade vem do canal autenticado e cadastro administrativo aprovado.
   Não aceitar identidade declarada pelo modelo, pelo relato ou por campos JSON.
   Permissões são verificadas no servidor para casos, memória e arquivos.

## Limites preservados

Bia intocável. Sem canal clínico, credencial de engenharia, tarefa automática
Codex, PR, build ou publicação iniciados pelo Jonh. O broker corporativo continua
o único remetente; ele recebe apenas a referência de uma intenção persistida.
Construção e publicação seguem o fluxo GitHub Free/GHCR canônico, sem compilar
na OCI, alterar orçamento ou executar testes pagos sem aprovação específica.

## Aceite operacional

Verificar com dados sintéticos, sem modelos pagos: texto com print; complementos;
isolamento; eventos duplicados; resposta antiga; ordem de reter; envio exato;
aceite seguido de entrega; resultado incerto e recuperação após reinício.
O conhecimento deve permitir contextualizar as áreas documentadas sem consultar
registros clínicos. Toda etapa não executada permanece explicitamente NOT_RUN.