[P3][detection][seed] Faixa de revisão como conceito de primeira classe: handoff opt-in para decisor externo, sem persistir valor e sem LLM no caminho crítico

[FabioLeitao]

U: U3 — sem pressão de prazo.
G: G2 — o desenho errado (persistir ou fazer hash do excerto) vira vazamento de PII; por isso o entregável é o contrato, não código.
Depende de: #1504 (schema do envelope), #1451 (achado 4: identidade da pilha no recibo), #1452 (calibração: a faixa vem de dado, não de palpite).

Contexto

O Boar já tem uma zona "não sei", espalhada por vários detectores (verificado por gh api no origin em 30/set):

• medium_confidence_threshold (padrão 40 em core/detector.py);
• fuzzy de nome de coluna entre fuzzy_min_confidence (25) e fuzzy_max_confidence (45), só se pedido em config e com o rapidfuzz instalado;
• hint de protótipo de embedding, que o próprio módulo descreve como "só na faixa borderline abaixo de MEDIUM" (core/embedding_prototype_hint.py);
• ML-only HIGH limitado a MEDIUM em contexto de entretenimento, legenda e OCR (docs/SENSITIVITY_DETECTION.md, limite 70).

Cada hint marca "confirme manualmente". Falta: (a) um conceito nomeado de faixa de revisão; (b) um contrato para que um decisor externo e opt-in ajude nessa faixa; (c) prova de que, sem ele, nada muda.

Doutrina que o contrato não pode quebrar

• Nenhum LLM decide achado no caminho crítico (audit(reproducibility): close the DL reproducibility contract & record pipeline identity in evidence #1451; docs/SENSITIVITY_DETECTION.md; TECH_GUIDE, seção "Detection stack vs generative LLMs").
• FN-first: regex forte continua HIGH (docs/SENSITIVITY_DETECTION.md).
• Só metadados: o Boar não guarda o valor encontrado (README).

Proposta (síntese do Claude, a confirmar)

1. Nomear e medir a faixa: definição normativa, com os limiares reais citados (confirmar os nomes com git grep -n), derivada da calibração da audit(detection-validity): ground-truth corpus, per-engine ablation, calibration & provenance (promote deferred plan) #1452 (taxa real de positivos por banda de score), não de números fixos.
2. Campo no envelope ([research][evidence-envelope] Unify trust_state, crypto_controls_audit, attestation, and release integrity into one evidence envelope #1504): review_band mais o motivo (quais detectores estão na faixa, com os scores por motor nomeados na audit(detection-validity): ground-truth corpus, per-engine ablation, calibration & provenance (promote deferred plan) #1452), sem o valor.
3. Handoff em duas classes, ambas opt-in e default OFF:
   • Classe M (só metadados): nome de coluna normalizado, tipo, contagens, scores e padrões disparados. Serve a consumidores cegos a valor bruto. A v1 é só esta.
   • Classe R (excerto real): exige grant assinado e escopo por coluna; o excerto amostrado fica só em memória, vai por pipe local a um processo efêmero, sem persistência e sem rede. Fora da v1 (recomendação); exige decisão explícita do operador e revisão de segurança.
4. Retorno é hint, nunca veredito: mesmo padrão dos hints existentes. Só pode elevar a confiança ou anotar, dentro da faixa, com o rótulo "confirme manualmente". Nunca rebaixa um achado (FN-first). Registra a identidade do consumidor e a versão do contrato.
5. Sem consumidor, sem mudança: o resultado é idêntico ao de hoje e o recibo registra um degradation_mode nomeado (mesma linha da audit(reproducibility): close the DL reproducibility contract & record pipeline identity in evidence #1451 e da audit(detection-validity): ground-truth corpus, per-engine ablation, calibration & provenance (promote deferred plan) #1452), nunca silencioso.
6. Privacidade do registro: não gravar hash do excerto. Identificadores como CPF têm pouca entropia, e o hash é reversível por força bruta. Gravar só ids de amostra, contagens e o hash do envelope de decisão.
7. O Boar não embute nenhum modelo. Implementações do decisor (regra determinística, NER, modelo pequeno) ficam fora e são escolha do operador.

Fora de escopo

Implementar o decisor; escolher modelo; mudar limiares.

Critérios de aceite

• Criar docs/plans/PLAN_REVIEW_BAND_HANDOFF.md com <!-- plans-hub-summary: ... -->.
• Executar python scripts/plans_hub_sync.py --write.
• Adicionar entry em docs/plans/PLANS_TODO.md.
• Definição normativa da faixa, com os limiares reais confirmados por git grep -n 'medium_confidence_threshold', ligada à calibração da audit(detection-validity): ground-truth corpus, per-engine ablation, calibration & provenance (promote deferred plan) #1452.
• Schema JSON versionado do handoff classe M (campos, sem valor bruto).
• Teste: sem consumidor, a saída é idêntica à atual e o degradation_mode fica registrado.
• Teste negativo: nenhum valor bruto nem hash de excerto aparece no recibo, no log nem no envelope.
• Decisão do operador registrada sobre a classe R (recomendação: fora da v1).
• docs/CLAIMS.yml atualizado se houver claim novo; README e TECH_GUIDE sem afirmar LLM.

Fila e PR

Uma issue; no máximo 1 PR (plano, schema e testes); nunca uma PR por item. Prioridade e milestone são sugestão; o sequenciamento é do operador.

Relacionado: #1504, #1451, #1452, #1169, #1104.

🤖 Registrado por Claude (Opus 4.8, T14, auditor RO), a pedido do operador em 30/set/2026. Verificado por gh api no origin; nada executado. Implementação: Cursor. Tom recomendatório.

[FabioLeitao]

Regra do operador para qualquer sidecar: licença própria e zero trust bidirecional (30/set)

Vale para o handoff da faixa de revisão (em especial a classe R, com excerto real) e para qualquer sidecar que o Boar venha a chamar:

• Licença própria: o sidecar carrega a sua licença/grant; sem ela, fica OFF, nunca "grátis".
• Zero trust nos dois sentidos: (1) o sidecar só processa payload depois de validar um grant assinado do Boar (escopo por coluna, capacidade, expiração); (2) o Boar valida o sidecar antes de enviar o primeiro byte (produto, versão e, quando aplicável, identidade do modelo: nome, revisão, sha256), e recusa um sidecar que se identifique como mock. Nenhum lado confia no dado do outro: validação de forma e tamanho na entrada e na saída, sem log de payload.
• Falha fechada: qualquer verificação que falhe encerra o handoff, e o recibo registra o degradation_mode; o resultado do Boar não muda.

O ecossistema já tem a metade "o sidecar verifica o chamador" (por exemplo o handshake.py do Stoat: "no attestation, no transform"). A metade "o chamador verifica o sidecar" é nova e deve entrar no PLAN desta issue. Não li a verificação de assinatura do Stoat; é mapa de papéis.

🤖 Claude (Opus 4.8, T14, auditor RO). Tom recomendatório; nada implementado.

[FabioLeitao]

Correção (30/set, erro meu): no comentário acima eu disse que "a metade 'o chamador verifica o sidecar' é nova". Está errado. O Boar já tem o SDK bidirecional de atestação mútua — #1116 (CLOSED), ADR-0087, core/sdk/mutual_attestation.py (MeshRole host/guest, trust_is_acceptable_for_guest, challenge/response Ed25519, Safe-Hold em peer adulterado; PLAN_SDK_BIDIRECTIONAL.md). A classe R reusa esse contrato; o específico daqui é só o Boar exigir, no handshake, a identidade do decisor (produto/licença, versão, e — se for modelo — nome/revisão/sha256, recusando mock). Descoberto porque o Codex CLI apontou o PLAN_SDK_BIDIRECTIONAL.md que eu não tinha lido.

🤖 Claude (Opus 4.8, T14, auditor RO). Correção de imprecisão própria.