Contexto
Sessão de 2026-08-09: três peças desconectadas convergiram no mesmo dia, sem coordenação
deliberada entre elas:
Observação
O repositório começou a mostrar o plano pela estrutura do produto, não só pelos documentos.
Isso sugere um próximo salto natural: um evidence envelope único que amarre trust_state
crypto_controls_audit + atestação (identidade/assinatura) + release integrity (SSHSIG) +
telemetria OTel num mesmo artefato — findings + condições de execução sob as quais foram
encontrados + trust reasons + crypto/control posture + identidade/attestation + versão/config
relevante.
Isso é uma diferença de categoria, não incremental: o relatório deixa de dizer só "achei X" e
passa a dizer "achei X, sob estas condições verificáveis, com este nível de confiança que
consigo defender mecanicamente" — sem o scanner virar juiz de conformidade jurídica, só uma
testemunha melhor. Aproxima o produto da fronteira entre data discovery, compliance
engineering e evidence engineering.
O que já existe (não é greenfield)
O que falta é a costura: um schema único de evidence envelope, em vez de N sinais espalhados
em N lugares diferentes do relatório.
Status
Lead de pesquisa, não feature comprometida ainda. Aberta como issue (em vez de ficar só
em conversa/backlog) porque ideias sem issue tendem a ser adiadas ou só enriquecidas
indefinidamente sem nunca cristalizar em trabalho rastreável.
Se/quando isto virar feature escopada, AC obrigatória: criar
docs/plans/PLAN_EVIDENCE_ENVELOPE.md, executar scripts/plans_hub_sync.py --write,
adicionar entry em docs/plans/PLANS_TODO.md.
Aberta por Claude Code (auditor RO) a pedido do operador — captura de insight estratégico
da sessão, não decisão de escopo/prioridade.
Contexto
Sessão de 2026-08-09: três peças desconectadas convergiram no mesmo dia, sem coordenação
deliberada entre elas:
insecure=do OTel (core/otel_setup.py, [P2][feat] Instrument Data Boar with OpenTelemetry (RED metrics + traces) — code-level, receiving end already live #1500 / PR feat(otel): opt-in OpenTelemetry RED metrics and traces (#1500) #1503) — TLS real por default,plaintext só permitido em loopback (
127.0.0.1/localhost/::1).--validate-cryptoopt-in (PR feat(scan): Order 5 Phase 1 — opt-in --validate-crypto wiring #1501, "Order 5 Phase 1", mergeada hoje) — coleta desinal de crypto agora gateada atrás de flag explícita; Fases 2–4 ("full TLS criteria,
heuristics, report sheet") já reservadas no plano Order 5.
data-boar-site#59) cortando query string e referrercompleto pra bater de fato com a política zero-PII do
PLAN_SITE_ANALYTICS.md, não sódeclará-la em prosa.
Observação
O repositório começou a mostrar o plano pela estrutura do produto, não só pelos documentos.
Isso sugere um próximo salto natural: um evidence envelope único que amarre
trust_statecrypto_controls_audit+ atestação (identidade/assinatura) + release integrity (SSHSIG) +telemetria OTel num mesmo artefato — findings + condições de execução sob as quais foram
encontrados + trust reasons + crypto/control posture + identidade/attestation + versão/config
relevante.
Isso é uma diferença de categoria, não incremental: o relatório deixa de dizer só "achei X" e
passa a dizer "achei X, sob estas condições verificáveis, com este nível de confiança que
consigo defender mecanicamente" — sem o scanner virar juiz de conformidade jurídica, só uma
testemunha melhor. Aproxima o produto da fronteira entre data discovery, compliance
engineering e evidence engineering.
O que já existe (não é greenfield)
O que falta é a costura: um schema único de evidence envelope, em vez de N sinais espalhados
em N lugares diferentes do relatório.
Status
Lead de pesquisa, não feature comprometida ainda. Aberta como issue (em vez de ficar só
em conversa/backlog) porque ideias sem issue tendem a ser adiadas ou só enriquecidas
indefinidamente sem nunca cristalizar em trabalho rastreável.
Se/quando isto virar feature escopada, AC obrigatória: criar
docs/plans/PLAN_EVIDENCE_ENVELOPE.md, executarscripts/plans_hub_sync.py --write,adicionar entry em
docs/plans/PLANS_TODO.md.Aberta por Claude Code (auditor RO) a pedido do operador — captura de insight estratégico
da sessão, não decisão de escopo/prioridade.