
Dois testemunhos discordaram sobre meu servidor. Ambos estavam certos.
Na manhã de 15 de agosto de 2026, uma mensagem chegou da Espanha.
"Seu servidor MCP está morto. 522."
Meu próprio monitoramento mostrou sete dias de verde. Cada amostra noturna dizia acessível: verdadeiro. Então, ou alguém estava mentindo, ou um instrumento estava quebrado. Isso é o que você assumiria.
Aqui está a conclusão logo de cara: ambos os relatos estavam corretos. E a contradição entre eles iluminou um limite que nenhum dos lados poderia ter encontrado sozinho. Este artigo é o relato completo e o registro do que fiz com o incidente em vez de enterrá-lo.
Contexto
Sou um carpinteiro em Hiratsuka, Japão. Trinta anos em canteiros de obras. Hoje em dia, também administro um servidor MCP que fornece a agentes de IA uma verificação de preço justo de terceiros para estimativas de construção, e um portão de verificação (hs-verify-gate) que mede todos os pontos finais em um registro público todas as noites e publica os resultados à medida que chegam. Meus próprios servidores são medidos sob as mesmas regras.
Testemunha A: o portão do operador
Invocado pelo cron do Cloudflare, medindo todas as noites de dentro da mesma conta do Cloudflare. Amostras reais da história pública:
2026-08-09T01:18:56.366Z acessível: verdadeiro record_sha256: d4ff4a21...
2026-08-13T18:00:38.235Z acessível: verdadeiro record_sha256: 4d204e6a...
2026-08-14T18:00:38.072Z acessível: verdadeiro (varredura noturna, seis pontos finais, todos alcançados)
Uma semana de verde. Cada amostra honesta, cada amostra hashada.
Testemunha B: babyblueviper1
De sua própria rede, curl simples, invocando a verificação HTTP pública do portão. Seu relatório:
acessível: falso
mcp_endpoint: inicialização falhou: http 522
fetche de cartão do agente: 522
E antes de confiar em qualquer coisa, ele recalculou o record_sha256 do portão ele mesmo: removeu os dois campos excluídos, canonizou, hashou, confirmou a correspondência, e só então relatou. Você não encontrará melhores maneiras em um testemunho.
A reprodução do operador
Eu reproduzi no mesmo dia.
2026-08-14T23:18:50.259Z portão /check para alvo acessível: falso, http 522
mesmos minutos inicialização direta para alvo HTTP 200
2026-08-14T23:22:44.151Z portão /check para segundo ponto final na mesma zona idêntico 522
portão /check para host fora da zona alcançado (405, como esperado)
O alvo estava ativo o tempo todo. Dois monitores comerciais de vivacidade e um cliente residencial estavam recebendo 200s dele na mesma janela. Apenas as verificações invocadas por HTTP do portão falharam.
O mecanismo
Os Cloudflare Workers têm uma proteção contra loops de subsolicitações, e essa proteção se baseia na zona em que a solicitação de entrada chegou. Três regras, todas medidas:
Entrada HTTP (zonal) para domínio personalizado da mesma zona : bloqueado, 522
entrada cron (sem zona) para domínio personalizado da mesma zona : permitido
qualquer entrada para o mesmo trabalhador (auto) : bloqueado
A Testemunha A mediu de um contexto que a proteção permite. A Testemunha B acionou um contexto que bloqueia. Ambos relataram exatamente o que sua perspectiva mostrava.
E aqui está o ponto: nenhum poderia ter descoberto esse limite sozinho. A semana de verde do operador nunca poderia revelar a proteção. O 522 externo sozinho nunca poderia localizá-lo. Dois relatos honestos e conflitantes tiveram que existir ao mesmo tempo antes que o limite se tornasse conhecimento.
A correção
Corrigido em 15 de agosto de 2026, em público.
As sondagens invocadas por HTTP para pontos finais na minha própria zona agora passam por um trabalhador de retransmissão fora do caminho da zona, cada salto na borda pública. E cada veredicto desde então carrega três coisas:
probed_via, divulgando o caminho que o mediu. A perspectiva é parte da medição.
acessível: nulo quando o próprio instrumento falha, então uma falha de instrumento nunca é registrada como uma falha de alvo.
gate_commit, o commit que produziu o veredicto, incluído dentro do registro hashado.
A história da reparação é pública no repositório (commits 2a1dfc91 até 8b0b5fc2). Como consequência da correção, o portão mediu seu próprio ponto final pela primeira vez.
Lições
Uma história verde só significa verde daquela perspectiva. Monitoramento que esconde sua perspectiva engana honestamente.
Uma única testemunha pode errar ao relatar honestamente. Duas testemunhas conflitantes não podem ser descartadas.
Nunca registre uma falha de instrumento como uma falha de alvo. Se você não conseguiu alcançá-lo, a resposta é acessível: nulo.
O que eu fiz com o incidente
Eu não o enterrei. Eu o inverti.
O relato completo se tornou o Registro de Discrepância 0001, ancorado como entrada 20 em um livro público, confirmado no bloco Bitcoin 962511 (2026-08-15 02:44 UTC). Você pode verificá-lo agora:
curl -s "https://ledger.horizonshield.dev/ledger/20?format=raw" | shasum -a 256
O hash que você recebe de volta corresponde a isto:
4b58ec1e04ec8a987826dbaa9fd334c0239ab3cd426363695fc853c65d0fd13e
O livro é chamado NENRIN, a palavra japonesa para anéis de árvore. A especificação é ancorada como entrada 19 no bloco Bitcoin 962507. O mecanismo se encaixa em três linhas. Qualquer um pode medir meus servidores de fora e enviar a observação para o livro. O código não tem rota para mim, o operador, recusar uma submissão válida. Cada registro carrega um timestamp ancorado em Bitcoin, então nada pode ser pintado depois.
Os limites são declarados, não ocultos: 64KB por registro, 50 por dia, 5 por IP. Assinaturas inválidas são rejeitadas. Registros não assinados são aceitos e marcados como não assinados.
Uma árvore adiciona um anel por ano, e ninguém pode pintar um depois. É por isso que os anéis provam a idade. Este 522 me ensinou que a confiança em um serviço só pode acumular da mesma forma.
Um convite
Se você executa monitoramento ou medição de qualquer tipo: suas observações podem se tornar registros permanentes e citáveis sob seu próprio nome e perspectiva. Se seu relatório conflitar com o que meu próprio portão diz, essa é a melhor submissão possível. Discrepâncias não são uma vergonha aqui. Elas são o produto.
Recepção de testemunhas (GET retorna uma auto descrição): https://ledger.horizonshield.dev/witness
O livro: https://ledger.horizonshield.dev/ledger
Código e texto completo: https://github.com/ogasurfproject-jpg/horizon-shield
O artigo destaca a importância de relatórios de monitoramento precisos e a necessidade de transparência em sistemas de verificação. Para empresas brasileiras, isso pode significar a adoção de práticas mais rigorosas em suas infraestruturas de TI e monitoramento de serviços.
