O núcleo de registro e encaminhamento foi implementado. A integração operacional, a escolha do modelo, a credencial e o orçamento permanecem pendentes.
Verificação do núcleo: 22 testes aprovados, zero falhas e zero chamadas pagas.
Data: 28/10/2026. Base documental: v2.0 integral revisada. 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.
Fontes preservadas
Registro aprovado em Markdown · PDF v2.0 histórico, sem alterações · Política aprovada