mirror of
https://github.com/melgarafael/DeskcommCRM.git
synced 2026-10-02 01:28:34 +08:00
Varredura de "afirmações de estado": toda frase que afirma como o mundo ESTÁ e
que portanto pode ter envelhecido. 393 afirmações medidas contra a fonte em 11
grupos de documento, cada uma com o comando que a responde. 166 confirmadas, 227
com problema, 4 vereditos VERDADEIRA derrubados por um passe adversarial.
E a primeira coisa que a varredura derrubou foi uma frase que EU escrevi hoje.
## O pior achado, e é meu
O runbook dizia "**Desde a 1.3.0**, o agente completa o pin sozinho — em até 5
minutos". Falso. O `completar_pin_ausente` entrou em `81b3bd5d` (2026-08-14),
POSTERIOR à v1.3.0 (2026-08-13), e a v1.3.0 continua sendo a tag mais recente:
$ git show v1.3.0:hostgator-setup-kit/_common.sh | grep -c completar_pin_ausente
0
Nenhuma instalação existente tem esse comportamento. E o `update.sh` faz
`git checkout "$TARGET_TAG"` — o kit que roda na VPS é o da TAG, não o da `main`.
Quem atendesse um cliente lendo aquela linha diria "espere cinco minutos que se
resolve", e nada aconteceria, para sempre.
O erro é exatamente o que esta sessão passou o dia caçando: **provei presença na
main e afirmei comportamento na versão publicada.** A mesma frase estava no
CHANGELOG, e pior — dentro da seção `## [1.3.0]`, não em `[Não lançado]`. As duas
corrigidas, e a entrada foi para onde pertence.
## O segundo: o aviso que declarava não-provado o que o documento prova
O topo do runbook dizia "ainda não coberto: app contra Supabase real, sessão de
WhatsApp pareada". O §P4 do MESMO arquivo, 340 linhas abaixo, documenta as duas
coisas na produção. Faltava uma palavra — "pelo ENSAIO" — e sem ela o primeiro
parágrafo que qualquer leitor vê mandava refazer trabalho já feito.
## Três documentos mandavam o leitor agir errado
- **`triagem/TRIAGEM.md`**: "Obrigatórios no merge: verify, build-and-size,
invariants" — três de cinco, faltando `e2e` e `imagens-ok`. É o arquivo que
DEFINE a triagem, e o CLAUDE.md registra que medir contra a régua errada é o
modo de falha número um dela. Agora traz o comando, não a lista.
- **`docs/deploy-hostgator/README.md`**: mandava o comprador leigo instalar um
autenticador e esperar um QR de MFA "no primeiro login". Com o MFA opcional, o
`bootstrap-owner.ts` grava `mfa_required: false` e essa tela não aparece — o
leigo concluiria que a instalação falhou. É o guia P0 de primeira impressão.
- **`ARCHITECTURE.md`**: "MFA TOTP forçado pra admin/super-admin", a regra antiga.
O CLAUDE.md já tinha a nova; a porta de entrada linkada pelo README, não.
## A régua de RAM: duas parcelas medidas, uma herdada
"~150 MB por número de WhatsApp" aparece em SETE documentos que se citam entre si
e **nunca foi medido neste projeto** — vem da síntese do curso WAHA (2026-05). Fui
medir na produção: o contêiner `waha` inteiro em **304,5 MiB com uma sessão
pareada**, contra `mem_limit` de 1280. Um ponto não decompõe baseline e sessão.
A parcela agora está marcada como herdada, com o comando para quem quiser medir.
**O tier recomendado não muda** — a régua dos 4 GB é a soma da stack em operação,
não o WAHA isolado, e os materiais comerciais não foram tocados.
## Segurança: corrigi o fato, não rebaixei o risco
O `docs/threat-model.md` afirma que não há limite de tentativa em login, signup e
aceite de convite. `lib/auth/rate-limit.ts` existe desde 13/08 e cobre os quatro
pontos, com limites nomeados. **Não rebaixei o T1**: isso pede reauditoria com
teste contra instância viva, que o próprio `confidence` do documento diz nunca ter
havido. Corrigi os fatos e marquei a reauditoria como devida.
Uma sub-afirmação sobrevive à letra e morre no espírito, e ficou registrada: a
sonda do doc (`grep lockout|failed_attempts`) devolve ZERO ainda hoje — mas
`rate-limit.ts:158` conta falha de login POR CONTA. A sonda é cega para a defesa
que existe.
## O gate novo, e ele nasceu vermelho pelo motivo certo
`documentacao-aponta-para-o-que-existe.test.ts` vigia a classe inteira nos 36
documentos de AUTORIDADE: link relativo morto, path em crase que não existe, e
frase de pendência que sobreviveu à pendência.
Escopo deliberado: `docs/stories/`, `docs/handoffs/` e `docs/specs/` ficam de fora
— são planejamento, e incluí-los faria o gate nascer com 384 violações e ser
desligado na primeira semana. Nos 36 de autoridade havia UMA, e ela é honesta (o
runbook cita o script e declara que ele não existe): congelada com justificativa.
Ele nasceu vermelho e estava certo — pegou sozinho duas notas de pendência que a
varredura tinha achado e eu ainda não corrigira, em CONTRIBUTING.md e na doutrina.
Quatro sabotagens, cada uma derrubando exatamente 1 dos 4 — inclusive a do escopo
vazio, porque um gate que varre zero arquivo passa verde. Sabotei DEPOIS de deixar
o controle verde: na primeira tentativa o controle já falhava, e as sabotagens não
provavam nada. E `git add -N` antes, porque `git checkout` não restaura arquivo
que o git ainda não conhece — a sabotagem do escopo ficou aplicada e só apareceu
no run seguinte.
## O que NÃO entra aqui
227 achados; apliquei os de gravidade alta cuja consequência é alguém agir errado.
Os de gravidade média e baixa — sobretudo contagens que envelheceram em
`docs/current-state.md` e `docs/harness-audit.md` — ficam listados no relatório,
não corrigidos. Aplicar 227 correções de texto num commit seria trocar prosa velha
por prosa não verificada.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RKm2XcTcfgi1vdMcDYSRWa