DRS (bloco 6, F.3) e Ap.6. As 17 telas do sistema (login, lista de relatórios, clientes, pasta do cliente, wizard de 4 passos, direção e prompt, compositor com ajuste fino, templates, página pública, modal de publicação, modo apresentar, analytics, identidade da agência, usuários, painel do Super Admin, painel do cliente) com o design system da plataforma-mãe no chrome do app e a linguagem visual das páginas de resultados no leitor público, base compartilhada e Mapa do mockup flutuante.

Como verificar (teste primeiro): todas as páginas respondem 200 na URL publicada; cada tela reflete a superfície correspondente do bloco 7 (F.1); smoke visual página a página em desktop e mobile.

Aceite (H1): Dado o mockup publicado, Quando o cliente navega pelo Mapa do mockup, Então alcança toda tela do sistema, E cada tela aparece com a identidade oficial da plataforma-mãe.

Gate. Apresentado e aprovado.

Como verificar (teste primeiro): aprovação registrada; DRS declara o mockup (bloco 6, F.3) REFERÊNCIA VISUAL APROVADA e GUIA DO DESENVOLVIMENTO.

Aceite (H1): Dado o mockup aprovado, Quando a construção de uma tela começa, Então a página correspondente do mockup é o guia, E divergência visual se resolve consultando o mockup.

DRS I.1, Ap.8; artefato ART-MIG-02 do Inventário. Montar o conjunto de referência da Fatia 1: converter relatórios reais do formato v2 para o contrato v3 (blocks[] com id, data_points com dp: e source), a partir dos relatórios reais já entregues e dos artefatos crus quando existirem; onde só há o valor formatado, marcar provenance: "legacy". Incluir os casos: os relatórios reais completos, o export adversarial com número inflado (fail-loud), e casos fora do nicho.

Como verificar (teste primeiro): o script de conversão v2 para v3 roda sobre os relatórios reais e produz documentos v3 válidos com id por bloco e dp: por número; o caso adversarial fica marcado como tal; o conjunto tem os relatórios reais, o adversarial e ao menos dois fora do nicho.

Aceite (H1): Dado o acervo de relatórios reais em v2, Quando o script de conversão roda, Então cada relatório vira um documento v3 com bloco id estável e todo número com dp: (ou provenance: legacy quando só há o formatado), E o golden set inclui os reais, o caso adversarial de dado inflado e casos fora do nicho.

RF-BND-001. Na Fatia 1 a fronteira é declaração de princípio no código do package e da composição: nenhuma função escreve no domínio de metas contínuas do módulo results; o Reports não modela input semanal nem série temporal viva de KPI. A varredura de rotas que prova a fronteira na aplicação real roda em F6/F7, quando as rotas do Reports existem.

Como verificar (teste primeiro): o código do package e da composição não importa nem escreve nenhum domínio de metas contínuas do results; nenhuma estrutura de dado do protótipo modela input semanal.

Aceite (H1): Dado um pedido para acompanhar uma métrica ao longo do tempo com metas semanais, Quando o operador está no ModularReports, Então o sistema não oferece input semanal nem série temporal viva de KPI, E nenhuma tela do Reports grava ou atualiza registro no domínio de metas contínuas do módulo results.

RF-ING-003, RF-CMP-009 (parte do parse). Container efêmero sem rede de saída que recebe os bytes do artefato e devolve JSON estruturado saneado; defesas de arquivo malicioso (magic bytes, XXE desligado, limite de razão de descompressão, SVG sanitizado, xlsm rejeitado); a falha é POR ARQUIVO (fail-closed por arquivo): o arquivo falho é rejeitado com o motivo apontado ao operador e vira lacuna declarada, sem derrubar o parse dos demais do lote, e nunca degrada aberto. É o único processo de fato isolado do pipeline.

Como verificar (teste primeiro): o container de parse não resolve DNS externo; um xlsm é rejeitado, um SVG com script é sanitizado, um zip bomb acima da razão limite é recusado; num lote de vários arquivos com um falho, o falho é excluído com motivo e vira lacuna, e os demais seguem.

Aceite (H1): Dado um arquivo submetido ao parse, Quando o parser roda, Então ele executa sem acesso de rede de saída e devolve JSON saneado, E um xlsm é rejeitado, um SVG com script é sanitizado, um zip bomb acima do limite é recusado, E a falha de um arquivo do lote o exclui com motivo e vira lacuna sem derrubar os demais (fail-closed por arquivo).

RF-CMP-005. Extrator por código lê célula/campo e injeta o valor; a IA escreve só narrativa.

Como verificar (teste primeiro): para um artefato com valores numéricos, todo número exibido é rastreável ao extrator, nenhum vem do texto gerado pelo modelo.

Aceite (H1): Dado um artefato com valores numéricos, Quando o pipeline compõe, Então todo número exibido no relatório provém do extrator determinístico ligado a uma célula ou campo, E nenhum número exibido é gerado pelo texto do modelo de linguagem.

RF-CMP-006. Cada número referencia dp:<id> com origem (artefato mais localizador, ou fonte externa da allowlist); número sem dp: é sinalizado como pendência.

Como verificar (teste primeiro): todo número colocado num bloco carrega dp:<id> resolvível; um número sem dp: aparece na lista de pendências.

Aceite (H1): Dado um relatório em composição, Quando um número é colocado num bloco, Então ele carrega um dp:<id> cuja origem aponta para um artefato e localizador ou uma fonte da allowlist, E um número sem dp: é sinalizado como pendência.

RF-CMP-008. Check determinístico confere a direção afirmada (melhorou/piorou) contra a comparação numérica de origem.

Como verificar (teste primeiro): um caso com narrativa invertida (diz "melhorou" com número que piorou) é sinalizado pelo check.

Aceite (H1): Dado um número cuja narrativa afirma uma direção (subiu, caiu, melhorou, piorou), Quando o check de polaridade roda, Então a direção afirmada é conferida contra a comparação numérica de origem, E uma inversão é sinalizada.

RN-012, RF-CMP-018; golden set de {F1-00}. Mecanismo por código, não por IA: não supressão do fato adverso aritmético (gasto maior que zero e conversões igual a zero, meta de CPA excedida, receita igual a zero com gasto maior que zero); selo calculado por código na métrica âncora derivada do campo objetivo_campanha do briefing (enum fechado do Ap.1) pelo mapa objetivo para métrica primária (parâmetro do ART-CFG-01, seed default por objetivo), não editável, não removível pela narrativa; pureza de canal (o label do dp: entra sanitizado por metric_id, nunca concatenado no corpo da instrução). Provar contra o golden set de {F1-00}, incluindo o caso adversarial de tentativa de supressão via evitar da direção; no compositor, o bloco do fato adverso aparece protegido e esconder é recusado na hora com o motivo (RF-CMP-018).

Como verificar (teste primeiro): um caso golden com gasto maior que zero e conversas igual a zero forçando supressão via evitar é bloqueado no publish; a métrica âncora sem selo é bloqueada; um label malicioso de dp: não chega ao corpo da instrução (só o metric_id sanitizado chega).

Aceite (H1): Dado um relatório em que um fato adverso aritmético de RN-012 está presente nos dados mas ausente da composição, ou cuja métrica âncora publica sem o selo íntegro, ou com um badge de valência oposta ao selo, Quando o operador tenta publicar, Então a publicação é recusada, E o sistema aponta exatamente o fato suprimido, o selo ausente ou o badge contradito.

RF-CMP-010. Wizard é UI sobre a API; a separação compor versus publicar é por capability (reports.compose versus reports.publish), não por escopo de token; nenhum ator de serviço carrega reports.publish. A composição interna roda com claims de sistema, com reports.compose e jamais reports.publish.

Como verificar (teste primeiro): um ator com reports.compose mas sem reports.publish que tenta publicar é recusado; publicar só funciona numa sessão humana com reports.publish.

Aceite (H1): Dado um ator com a capability reports.compose mas sem reports.publish, Quando ele tenta publicar um relatório, Então a publicação é recusada, E publicar só conclui a partir de uma sessão humana com reports.publish.

RF-CMP-011. A composição reusa o gateway de IA da plataforma-mãe (proibido client de IA próprio) com a cadeia gratuita (dois provedores gratuitos encadeados, primário e fallback); sem upgrade automático para modelo pago.

Como verificar (teste primeiro): inspeção do código mostra a composição chamando o gateway da plataforma-mãe, sem client de IA próprio; a configuração usa só a cadeia gratuita, sem fallback automático para modelo pago.

Aceite (H1): Dado o pipeline de composição, Quando ele roda em produção, Então usa apenas o gateway de IA da plataforma-mãe com a cadeia gratuita configurada, E nenhum upgrade para modelo pago acontece automaticamente sem decisão registrada.

RF-CMP-012. Cada composição registra tokens e tempo de processamento.

Como verificar (teste primeiro): ao final de uma composição, o registro de tokens e tempo existe e está disponível para acompanhamento operacional.

Aceite (H1): Dado uma composição concluída, Quando ela termina, Então o sistema registra tokens consumidos e tempo de processamento daquele job, E esses valores ficam disponíveis para o acompanhamento operacional.

RF-CMP-013. Tom de voz da ficha de identidade do cliente é injetado como parâmetro direto da narrativa.

Como verificar (teste primeiro): dois clientes com tons de voz diferentes ("técnico e sóbrio" vs "leve e próximo") geram narrativas com registro distinto.

Aceite (H1): Dado um cliente com tom de voz "técnico e sóbrio" e outro com "leve e próximo", Quando a IA compõe para cada um, Então a narrativa reflete o tom declarado do respectivo cliente, E o tom nunca é inferido em silêncio quando a ficha está vazia.

RF-CMP-014. Comparação com mercado só usa valores da allowlist, com fonte nomeada; sem allowlist disponível, comparação é interna.

Como verificar (teste primeiro): toda afirmação de comparação com mercado no relatório carrega fonte da allowlist; uma comparação sem fonte na allowlist não é emitida.

Aceite (H1): Dado uma afirmação de comparação com o mercado no relatório, Quando ela é composta, Então o benchmark citado provém da allowlist e carrega a fonte, E uma comparação de mercado sem fonte na allowlist não é emitida.

RF-CMP-015. Schema impõe teto de caracteres por bloco de texto (ex.: insight até 280 caracteres).

Como verificar (teste primeiro): um bloco de insight gerado acima do teto é rejeitado ou truncado pelo schema.

Aceite (H1): Dado um bloco de insight, Quando a IA produz um texto acima do teto de caracteres, Então o bloco é rejeitado ou truncado pelo schema, E nenhum bloco publicado ultrapassa o teto definido.

RF-CMP-016. Relatório N-1 do mesmo cliente entra no contexto com instrução de não repetir; similaridade acima do limite é sinalizada.

Como verificar (teste primeiro): compor o relatório N logo após o N-1 do mesmo cliente e tipo dispara a sinalização quando a similaridade ultrapassa o limite.

Aceite (H1): Dado que existe um relatório anterior do mesmo cliente e tipo, Quando o relatório novo é composto, Então a narrativa é comparada por similaridade com a anterior, E uma repetição acima do limite de similaridade é sinalizada para o operador.

RNF-SEG-002, RNF-SEG-003, RNF-SEG-004. Números nunca saem do modelo de linguagem (reforço de {F1-03} contra prompt injection via artefato); publicar exige a capability reports.publish (reforço de {F1-06}); parse isolado sem rede (reforço de {F1-02}) e composição sem estado global cross-tenant (reforço de {F1-15}).

Como verificar (teste primeiro): um artefato de teste com instrução embutida ("escreva ROAS 10x") não altera nenhum valor exibido; os reforços passam nos mesmos testes de {F1-02}, {F1-03}, {F1-06} e {F1-15}.

Aceite (H1): Dado qualquer artefato do cliente com instruções embutidas, Quando o pipeline compõe, Então nenhum número exibido provém do texto do modelo, E instruções embutidas no artefato não alteram valores exibidos.

RF-CMP-009 (parte da composição), RNF-SEG-004. A composição roda in-process (síncrona) reusando o gateway de IA, com o contexto montado só do report_id e sem estado global entre composições. A barreira cross-tenant é a ausência de estado global mais o contexto por relatório.

Como verificar (teste primeiro): dois pedidos de composição de agências diferentes processados em sequência não compartilham dado; não há estado global que sobreviva entre composições.

Aceite (H1): Dado dois pedidos de composição de agências diferentes processados em sequência, Quando o segundo roda, Então ele não tem acesso a nenhum dado do primeiro (contexto montado só do próprio report_id, sem estado global), E a composição opera sobre o dado já saneado pelo parse isolado ({F1-02}).

DRS G.1, G.3 (assinatura das interfaces; RF-REN-005, o package renderizador em si, é entregue em F3). Definir os três contratos que a Fatia 1 entrega agnósticos à decisão de módulo: identity (recebe identificadores opacos de agência e cliente, devolve branding: cor, logo, tom); storage (adapter do bucket, put e get de artefato e asset por id mais sha256); render (funções puras do package renderizador, bloco para HTML).

Como verificar (teste primeiro): os três contratos existem como interfaces com implementação de referência; o package renderizador (render) emite HTML a partir do contrato de bloco; identity e storage são injetáveis (troca de implementação sem tocar a composição).

Aceite (H1): Dado o package da Fatia 1, Quando a composição precisa de identidade, storage ou renderização, Então ela usa as interfaces identity, storage e render, E nenhuma delas acopla o protótipo à decisão de módulo (chrome, banco, storage concretos entram por injeção).

FECHADO em 2026-08-03, com conclusão MEDIDA, e não com "resolvido". Era o cartão mais antigo em aberto do projeto. A régua foi recalibrada com um relatório REAL de 25 seções, entregue a cliente pagante e anonimizado antes do parse (cliente, sub-marcas, cidades, concorrentes, domínio e identificadores de conta trocados; números e estrutura preservados). O resultado fecha a dúvida que travava o gate D: os dois documentos legados continuam reprovando, pela dimensão de honestidade comparativa, e passam limpos no critério novo. Ou seja, comprimento não explica a reprovação. A conclusão que fica registrada é: régua exigente contra a prática antiga da casa, e NÃO régua calibrada contra a escala errada. Isso confirma a decisão do dono em {Q6} de manter a régua exigente, e é por isso que o cartão fecha com essa frase e não com "resolvido". Veredito cru do relatório real, para constar: nota máxima nas cinco dimensões do critério antigo e média 3,33 no critério novo, que apontou eco entre seções distantes. Um documento que a operação entregou e o cliente pagou tira nota perfeita no critério que já existia e perde ponto no que acabou de nascer, o que é a melhor evidência possível de que o segundo critério faz falta. As duas pendências que o cartão esperava foram respondidas: o papel do golden legado como âncora de nota 4 caiu com {Q6} (o acervo antigo é material de referência de conversão, não padrão de qualidade), e a capacidade de IA gratuita para medir foi endereçada por {Q5} (stack de provedores gratuitos) e deixou de ser aperto quando se mediu que julgar custa 3 chamadas por documento, não 75.

Motivo de abertura original, MEDIDO em 2026-07-28 e preservado aqui como histórico. A rubrica está construída e validada: o juiz separa golden de degradado com folga (2,80 a 3,80 contra 1,20 a 1,80). Os gates A (zero alucinação numérica), B (tríade de segurança) e C (isolamento cross-tenant) estão VERDES. O gate D (qualidade da narrativa) segue aberto por dois fatos medidos: (1) dois dos documentos do golden set, que são conversões de relatórios LEGADOS entregues antes das regras do Ap.5, pontuam 2,80 com a dimensão de honestidade comparativa em 2 (comparação vaga sem dono nomeado), ou seja a régua nova reprova o padrão antigo da casa, e a premissa do card de que o golden equivale a nota 4 foi refutada pela medição; (2) a nota da composição PRODUZIDA pelo pipeline (que é o que o gate deveria medir) não pôde ser obtida porque a cota diária do provedor gratuito primário esgotou (100 mil tokens por dia, consumidos pelo próprio protótipo) com o segundo provedor gratuito fora do ar. Pendências que este card espera: decisão de produto sobre o papel do golden legado como âncora de nota 4, e capacidade de IA gratuita suficiente para medir (ver o Questionário).

DRS I.1, Ap.4; golden set de {F1-00}. Juiz por modelo de linguagem em temperatura 0, 3 passadas e mediana, calibrado com golden (nota 4) versus degradado (nota 1 ou 2), nas 5 dimensões (D1 a D5). Usa o golden set montado em {F1-00}.

Como verificar (teste primeiro): rodar o golden set de {F1-00} e o caso adversarial contra a rubrica; confirmar que o juiz separa golden (nota 4) de degradado (nota 1 ou 2); nenhuma composição publicável tem número sem proveniência ({F1-04}), isolamento cross-tenant quebrado ({F1-15}) ou publicação fora de sessão humana com reports.publish ({F1-06}); uma narrativa genérica sem âncora (sem ponto de dado, sem destaque do briefing, sem comparação nomeada) é reprovada pela rubrica (Ap.5 item 11); o A/B da taxa de composição sem edição (braço com a direção vazia versus braço com a direção preenchida) roda com a guarda: subir a taxa "sem edição" no braço preenchido não pode baixar D2 nem D3 da rubrica 5D em relação ao braço vazio.

Aceite (H1): Dado o golden set e o caso adversarial, Quando a rubrica roda, Então a média é maior ou igual a 3,0 com nenhuma dimensão igual a 1 e D2/D3 maiores ou iguais a 3, E os quatro gates HARD (zero alucinação numérica, tríade de segurança, isolamento cross-tenant, qualidade da narrativa) passam. Os indicadores de custo, latência e taxa de composição sem edição são termômetro NÃO bloqueante enquanto o conjunto de referência for pequeno (DRS J.4); os números de referência da Fatia 1 (não são gate) são: custo por página abaixo de US$ 0,50 em tokens, latência na faixa de 10 a 30 segundos (RNF-PERF-002) e ao menos metade dos blocos aceitos sem reescrita manual. Ficar muito fora desses números é sinal de revisar o pipeline, não de reprovar a fatia.

DRS E.1, E.2; artefatos ART-ENT-01 a 08 do Inventário. Migration que cria o schema reports com as 7 tabelas do E.2 (report, report_draft, snapshot, artifact, comment, link_event, template) mais report_goal (metas por cliente). Só a criação das tabelas; sem RLS, entitlement nem RBAC (esses vêm em F6). A report_job (evolução) e a agency_domain (Fatia 14) nascem nas suas fatias.

A ordem de criação respeita as FKs: template primeiro (referenciado por report.template_id, nullable), depois report, e por fim as que apontam para report (report_draft, snapshot, artifact, comment, link_event); report_goal referencia hub.accounts/hub.companies e não depende das outras. A migration cria também o trigger de integridade RN-009: um BEFORE INSERT/UPDATE em report que confere report.company_id contra o company_id do Account referenciado (hub.accounts.company_id) e rejeita gravar um relatório que cruze a agência de uma Company com o Account de outra.

Como verificar (teste primeiro): migration aplicada cria as 8 tabelas com as colunas do E.2; rollback remove tudo sem resíduo; rodar de novo é idempotente; inserir um report com company_id diferente do company_id do Account referenciado é rejeitado pelo trigger RN-009 (o par que bate é aceito).

Aceite (H1): Dado o banco do Hub sem o schema reports, Quando a migration de dados roda, Então as 8 tabelas (as 7 do E.2 mais report_goal) existem com as colunas, chaves e índices do bloco E.2 e das fichas do Inventário, E a migration é idempotente (rodar de novo não falha nem duplica).

RF-REN-001, Ap.2. blocks[], cada bloco com id estável, type, hidden?, tags?, props. id nunca regenerado (âncora de comentário e analytics). Publicar remove blocos ocultos do snapshot.

Como verificar (teste primeiro): republicar um relatório mantém o mesmo id de cada bloco não removido; um bloco marcado oculto some do snapshot.

Aceite (H1): Dado um documento de relatório, Quando ele é serializado, Então cada bloco tem um id estável que não muda entre republicações, E um bloco marcado oculto não aparece no snapshot publicado.

RF-REN-002. Tipos de bloco num registro declarativo (componente, schema, defaults); leitor ignora tipo desconhecido em silêncio, compositor sinaliza.

Como verificar (teste primeiro): um snapshot com um tipo de bloco fora do registro renderiza os demais blocos sem erro no leitor, e aparece sinalizado no compositor.

Aceite (H1): Dado um snapshot com um tipo de bloco que o leitor não conhece, Quando o cliente abre o link, Então a página renderiza os demais blocos sem erro e ignora o desconhecido, E no compositor o mesmo tipo desconhecido é sinalizado ao operador.

RF-REN-003. Payload carrega schema_version; leitor converte versões antigas por funções puras, sem reescrever o armazenado.

Como verificar (teste primeiro): um snapshot fixture em versão antiga renderiza correto após conversão em memória; o registro armazenado permanece na versão original após a leitura.

Aceite (H1): Dado um snapshot em versão de schema antiga, Quando o leitor o renderiza, Então ele o converte em memória para a versão corrente e exibe corretamente, E o registro armazenado permanece na versão original.

RF-PUB-001, RN-001, RN-002, RN-010. Publicar congela snapshot (blocos, metas vigentes, branding); editar depois não muda o já servido. A imutabilidade é imposta no schema (RN-010): a role de aplicação não recebe UPDATE direto em snapshot; a escrita acontece apenas pela função SECURITY DEFINER de publish/republish.

Como verificar (teste primeiro): alterar a identidade visual ou as metas do cliente após um publish não muda o relatório já publicado; editar o rascunho não altera o snapshot até novo publish; um UPDATE direto em snapshot pela role de aplicação é recusado (só a função de publish escreve).

Aceite (H1): Dado um relatório publicado, Quando a identidade visual do cliente ou as metas são alteradas depois, Então o relatório publicado continua exibindo os valores copiados no momento do publish, E editar o rascunho não muda o snapshot já servido até um novo publish, E um UPDATE direto em snapshot fora da função de publish é recusado (RN-010).

RF-ING-005, RN-006. Criativos e imagens referenciados por asset_id + sha256, nunca URL crua ou base64 no payload.

Como verificar (teste primeiro): inspecionar o payload de um bloco de mídia; confirmar ausência de URL crua e de base64 embutido.

Aceite (H1): Dado um criativo inserido num relatório, Quando o payload do bloco é gravado, Então o bloco referencia asset_id e sha256 do asset, E o payload não contém a URL crua nem o conteúdo base64 da imagem.

RN-001 a RN-006 (DRS E.4). Integridade cruzada: public_token vive no report (RN-001); snapshot.payload copia metas/branding (RN-002); todo número referencia dp: (RN-003); artifact respeita purge_after sem quebrar o publicado (RN-004); comment.block_id vira orphaned quando o bloco some (RN-005); asset por asset_id+sha256 (RN-006, reforço de {F2-05}).

Como verificar (teste primeiro): suíte de integridade cobre as 6 regras com um caso positivo e um caso de violação para cada.

Aceite (H1): Dado o schema reports povoado, Quando a suíte de integridade roda, Então as 6 regras de negócio de dados passam, E nenhuma violação passa despercebida.

RF-REN-004. Markdown sanitizado com allowlist em todos os consumidores (leitor, preview, PDF).

Como verificar (teste primeiro): um bloco com script embutido no corpo não executa em nenhum dos três consumidores.

Aceite (H1): Dado um bloco cujo corpo contém um script embutido, Quando qualquer consumidor renderiza o bloco, Então o script é removido pela sanitização, E nenhum HTML executável do corpo chega ao navegador do cliente.

RF-REN-005, ADR-008, RNF-MANUT-001. Funções puras que emitem HTML, versionado como package, sem segunda implementação de blocos no React ou na composição.

Como verificar (teste primeiro): um mesmo documento renderizado pelo leitor, pelo preview e pelo PDF usa as mesmas funções (mesma saída de HTML para os mesmos dados); busca no código não encontra uma segunda implementação de bloco.

Aceite (H1): Dado um mesmo documento de relatório, Quando ele é renderizado pelo leitor, pelo preview e pelo gerador de PDF, Então os três usam as mesmas funções do package renderizador, E não existe uma segunda implementação dos blocos fora do package.

RF-REN-007. Conjunto de tokens --r-* por cliente, aplicando as cores da ficha de identidade.

Como verificar (teste primeiro): dois clientes com paletas diferentes renderizam com os tokens do respectivo cliente; trocar a paleta de um não afeta a página já publicada do outro.

Aceite (H1): Dado dois clientes com paletas diferentes, Quando seus relatórios são renderizados, Então cada página aplica os tokens --r-* do respectivo cliente, E trocar a paleta de um cliente não afeta a página já publicada do outro.

RNF-A11Y-001. As duas superfícies de leitura atendem contraste AA nos tokens claro e escuro.

Como verificar (teste primeiro): auditoria de contraste automatizada (axe ou equivalente) nas duas superfícies com os dois temas de tokens.

Aceite (H1): Dado o leitor e o PDF renderizados com os tokens do cliente, Quando a auditoria de contraste roda, Então ambos atendem AA nos dois conjuntos de tokens (claro e escuro).

RNF-MANUT-001. O renderizador vive como package próprio com versão, não como código espalhado pelos consumidores.

Como verificar (teste primeiro): o package tem número de versão próprio e é importado (não copiado) pelos três consumidores.

Aceite (H1): Dado o package renderizador, Quando um consumidor precisa dele, Então ele importa a dependência versionada, E nenhum consumidor mantém cópia própria do código de renderização.

RF-ING-001. Aceita planilha, CSV, PDF, Markdown, JSON, imagem; recusa tipos fora da lista.

Como verificar (teste primeiro): subir um arquivo de cada tipo suportado é aceito; um tipo fora da lista é recusado com mensagem clara.

Aceite (H1): Dado o passo de dados do wizard, Quando o operador sobe um arquivo de tipo planilha, CSV, PDF, Markdown, JSON ou imagem dentro da quota, Então o arquivo é aceito e associado à composição, E um tipo fora dessa lista é recusado com mensagem clara.

RF-ING-002. Quota (nº de artefatos, MB, páginas de PDF) validada antes de tokenizar; limites admin-editáveis.

Como verificar (teste primeiro): subir um conjunto acima da quota é recusado antes de qualquer conteúdo chegar ao parse ou à composição; a mensagem aponta o limite ultrapassado.

Aceite (H1): Dado a quota configurada em N artefatos e M megabytes, Quando o operador sobe um conjunto que ultrapassa N ou M, Então o sistema recusa antes de enviar qualquer conteúdo à composição de IA, E exibe qual limite foi ultrapassado.

RF-ING-003. Ligar o upload ao sandbox de parse já construído em {F1-02} (container sem rede de saída, magic bytes, XXE desligado, limite de razão de descompressão, SVG sanitizado, xlsm rejeitado, fail-closed); o resultado saneado alimenta a composição.

Como verificar (teste primeiro): um arquivo subido pela ingestão passa pelo sandbox de {F1-02}; o container de parse não resolve DNS externo; um xlsm é rejeitado, um SVG com script é sanitizado, um zip bomb acima da razão limite é recusado.

Aceite (H1): Dado um arquivo submetido ao parse, Quando o parser roda, Então ele executa sem acesso de rede de saída, E um xlsm é rejeitado, um SVG com script é sanitizado, e um arquivo compactado com razão de descompressão acima do limite é recusado.

RF-ING-004, RNF-LGPD-001. Artefato apagado do storage após TTL curto; relatório publicado permanece íntegro.

Como verificar (teste primeiro): simular expiração do TTL de um artefato de um relatório já publicado; confirmar remoção do storage e integridade do relatório.

Aceite (H1): Dado um relatório publicado, Quando o TTL do artefato cru expira, Então o artefato cru é apagado do storage, E o relatório publicado continua íntegro sem depender do artefato.

FECHADO em 2026-08-05, com o aceite INTEIRO coberto. A última cláusula (ver o achado, com fonte e endereço, na página pública que o cliente abre) foi fechada com artefato real de campanha de cliente, não com amostra sintética: relatório composto e publicado de verdade, e a página anônima aberta e OLHADA em tela grande e em celular, mostrando "Fontes externas consultadas" com o nome da fonte e o endereço clicável dentro do bloco de confiabilidade. Conferido por conta própria e não pelo relato: a publicação existe no banco com a fonte externa dentro do retrato imutável, e o link foi revogado no fim (responde como encerrado), então nenhuma página de teste ficou viva. Duas tentativas anteriores, com amostra inventada, foram recusadas pelos gates de proveniência do número e de âncora de honestidade; os gates estavam certos e a saída foi satisfazê-los com dado real, nunca contorná-los.

CONSTRUÇÃO (contexto), deployada em produção em 2026-08-05. O motivo antigo caiu: o buscador que faltava já era infraestrutura da casa e só não estava ligado (o metabuscador próprio do vendor, com resposta em formato de dados habilitada, já estava anexado à rede interna do Hub, então o serviço da API fala com ele por nome, sem porta pública, sem serviço pago e sem container novo). Entregue e provado: filtro por domínio à prova de subdomínio, sósia e credencial embutida na URL, com a fonte alegada tendo de casar com o endereço do achado; sumarização por IA cujo prompt, por construção, não tem parâmetro que aceite artefato, ponto de dado ou bloco do cliente, com o conteúdo da web entrando pelo canal de dado não confiável e a guarda de separação reprovando ANTES do disparo; curadoria real do operador no passo de dados do assistente, com a etapa nascendo desligada, três estados de falha nomeados e distintos, e falha nenhuma reprovando o relatório; e o achado curado virando ponto de dado com marca de proveniência própria, que chega ao bloco de confiabilidade com fonte e endereço. Ao ligar isto, dois requisitos que estavam inalcançáveis desde a primeira fatia passaram a ser chamados pelo caminho real de composição: a instrução de fontes de benchmark e a separação entre canal de instrução e canal de dado.

A cláusula que falta: ver o achado, com fonte e endereço, na página pública real que o cliente abre. Foi verificado o texto renderizado pelo mesmo registro de blocos que o leitor usa, e o leitor foi exercitado à parte, mas a publicação que provaria a última milha não existe como artefato: nenhuma das quatro publicações vivas no banco contém fonte externa. Duas tentativas de publicar um relatório de teste com achado foram recusadas por gates de OUTROS requisitos (proveniência do número e âncora de honestidade), corretamente, por a amostra ser sintética. Fecha quando um relatório com dado real e achado curado for publicado e a página anônima for olhada.

RF-ING-006. Etapa opcional, roda sem os artefatos do cliente no mesmo contexto, só fontes da allowlist, achados com fonte e URL nomeadas.

Como verificar (teste primeiro): ligar a pesquisa de mercado num relatório de teste; confirmar isolamento de contexto e que cada achado usado carrega fonte e URL.

Aceite (H1): Dado que o operador liga a pesquisa de mercado para um relatório, Quando a etapa roda, Então ela executa isolada dos artefatos do cliente e consulta apenas fontes da allowlist, E cada achado usado no relatório carrega a fonte e a URL de origem nomeadas.

RF-BND-002. Sem gestão, CRUD, biblioteca persistente nem histórico de artefatos crus; nenhuma tela de acervo.

Como verificar (teste primeiro): varredura de rotas confirma ausência de tela de listagem/edição/reabertura de artefatos crus como acervo.

Aceite (H1): Dado um artefato subido para compor um relatório, Quando a composição termina e o relatório é publicado, Então o artefato cru é descartado após o TTL configurado, E não existe nenhuma tela no sistema que liste, edite ou reabra artefatos crus como acervo.

FECHADO em 2026-08-08, com as cinco fatias mergeadas e deployadas. A contagem que o cartão

exigia como primeiro passo derrubou o número do documento, e as fatias A a E deram caminho de

edição a todos os parâmetros que tinham ponto de chamada vivo, mais a tela dos atributos do

cliente. A última fatia fechou com a prova certa: baixar o limite pelo painel e a rajada seguinte

ser recusada, sem reiniciar nada.

Duas coisas ficam declaradas como NÃO feitas, e não escondidas: três parâmetros seguem sem

tela de propósito, porque não são chamados por caminho nenhum (dar configuração a guarda que

ninguém aciona entrega tela que grava e não muda nada), e eles dependem dos cartões {F8-16} e do

irmão de verbosidade; e a restrição de banco que espelha a regra da sazonalidade não entrou,

porque exigiria migration no outro repositório.

O achado mais caro da série não foi nenhum parâmetro, foi o padrão: um parâmetro que parecia

ter um ponto de bloqueio tinha cinco, três deles o mesmo limite copiado em rotas irmãs e um em

outro processo; e o gate que reprova publicar número sem procedência era chamado sem a

configuração, julgando sempre pela regra antiga. Em ambos, a tela gravava e o sistema ignorava.

Antes de dar qualquer parâmetro por configurável: contar os pontos de bloqueio dele, inclusive

fora do processo principal.

E a configurabilidade cria risco que o valor fixo não tinha: enquanto o número era constante,

ele era o teto. Ver {F8-18}.

CONTAGEM FEITA em 2026-08-05: 4 editáveis, 16 não, e a aritmética fecha em 20. O cartão nasceu

porque um parâmetro tinha sido medido como falso; a contagem exaustiva dos vinte, por leitura do

código real e dos três níveis (coluna no banco, rota com guarda de permissão, chamada de fato pela

tela), mostrou que o falso era a regra e não a exceção. Só têm caminho de edição por uma pessoa:

retenção de retratos e medição, identidade padrão da agência, tipos de relatório, e a promoção de

um tipo a global. Os outros dezesseis são constante congelada, com todos os pontos de chamada

usando o valor padrão.

A causa é sistemática e está escrita no código: o pipeline foi desenhado com o valor injetável

por parâmetro, como preparo para configuração futura, e vários arquivos trazem o comentário "até o

painel existir". O Inventário documentou essa INTENÇÃO como fato entregue. É a família de defeito

mais cara deste projeto outra vez: peça pronta e inalcançável.

RF-CMP-014, RF-ING-006, e os demais requisitos citados no {ART-CFG-01}.

RECONTAGEM do planejamento, e ela mudou o corte: dos treze que pareciam precisar de tela,

três não são chamados em lugar nenhum do caminho real. Dois já são o cartão {F8-16}; o terceiro

é o teto de verbosidade por bloco, que estava no balde errado. Ele não é "falta painel": é

guarda que ninguém aciona, e por isso o requisito que promete que nenhum bloco publicado ultrapassa

o teto não tem hoje quem o faça valer. Os três ficam DIFERIDOS até serem ligados, porque

configurar antes de ligar entrega uma tela que grava e não muda nada, que é o defeito exato que

este cartão conserta. Sobram nove com ponto de chamada vivo. A aritmética fecha: nove com tela,

um só-tela, um em fatia própria, três diferidos, duas correções de ficha, mais os quatro que já

funcionam, igual a vinte.

**O escopo real, depois de separar o que é de categoria diferente (tratar tudo junto seria errar de

novo): os parâmetros acima precisam de origem em configuração e tela; um** (a base sazonal) já

tem coluna e rota prontas e precisa só da tela; um (a lista de guardas que admitem exceção)

não deve ganhar painel, porque o próprio requisito que a ficha cita declara que ela é escrita em

código e não julgada na hora, então o defeito ali é a linha do Inventário e se corrige apagando a

promessa; e um (o limiar de alerta de excesso de ressalvas) não existe no produto, é feature

ausente e não parâmetro sem tela, então sai deste cartão e vira requisito próprio quando alguém

decidir construí-lo.

O que implementar: para os treze, a origem em configuração por agência e a tela que a edita,

respeitando o escopo declarado (global do Super Admin, por agência do Admin), e o ponto de chamada

passando a LER a configuração em vez do valor padrão, que é onde a metade do trabalho de verdade

mora: sem isso, a tela grava e a composição continua ignorando. Para a base sazonal, só a tela. Para

a lista de guardas, corrigir a ficha do Inventário.

Como verificar (teste primeiro): para cada parâmetro que ganhar tela, um admin de agência (ou o

Super Admin, conforme o escopo) altera o valor e a composição seguinte se comporta diferente,

sem migration e sem deploy; e a contagem publicada bate com o número de parâmetros com caminho de

edição provado.

FATIA A ENTREGUE e DEPLOYADA em 2026-08-05: quota de entrada e TTL do artefato cru. Com ela

nasceu o mecanismo que as próximas fatias reusam: um catálogo declarativo de onde a tela é gerada,

o formato da rota é derivado e o teste de exaustividade é percorrido, para não existir uma segunda

lista que alguém esqueça de atualizar; os valores padrão reexportados das constantes que já

existiam, nunca redigitados; e a resolução acontecendo uma vez na entrada de cada caminho real,

nunca ponto a ponto. Valor ausente cai no padrão de antes, valor inválido cai no padrão sem passar

calado (nomeia o campo e registra auditoria), e salvar uma parte não apaga as irmãs. Provado com o

admin mudando o valor pela tela e o sistema recusando na hora, sem migration e sem reinício.

A lição que esta fatia pagou, e que as próximas oito herdam: a quota não tinha um ponto de

bloqueio, tinha cinco, e quatro foram descobertos tarde. Três eram o mesmo limite fixo

duplicado em rotas irmãs; o quinto vivia em outro processo e por isso escapou até de quem

recontou dentro do Hub. Ligar um ponto e deixar os irmãos fixos é pior que não ligar nenhum, porque

o placar fica verde e a configuração passa a mentir. Antes de dar qualquer parâmetro por

configurável: contar os pontos de bloqueio dele, inclusive fora do processo principal.

A configurabilidade também criou risco novo, registrado no cartão {F8-18}: enquanto o valor era

fixo, ele era o teto.

FATIA B ENTREGUE e DEPLOYADA em 2026-08-08: os cinco parâmetros da comparação (tolerância de

largura de janela, desfecho da comparação parcial, métricas não somáveis entre janelas, limiar de

materialidade e histórico mínimo por tipo de bloco), que foram juntos por dividirem o mesmo

caminho. O mecanismo da Fatia A passou no seu primeiro teste real: cada parâmetro custou uma

entrada no catálogo mais a fiação inevitável no ponto de chamada, sem nenhuma segunda lista, e a

contagem de pontos de chamada bateu com o previsto, sem irmão escondido. Um dos pontos religados

vive no disparador do ciclo agendado, que roda sozinho e ninguém olha.

**A varredura de apoio dava OK falso de duas formas, e as duas foram fechadas com o caso que ela

DEVE reprovar:** ela só enxergava referência literal à constante, e deixava passar quem chamasse a

função sem informar o parâmetro; e, rodada do jeito natural, lia o catálogo já publicado e

ignorava os parâmetros da fatia em construção, passando verde por omissão. Agora ela resolve o

catálogo certo sozinha ou falha fechada, e um chamador adversarial de verdade prova que reprova.

Corrigido junto: a descrição de um parâmetro enganava o admin, sugerindo que tirar uma métrica

da lista faria o sistema somar entre janelas, quando o efeito real é a agregação deixar de rodar.

Quem edita precisa ler o que o sistema faz, não o que o nome sugere.

**FATIA C ENTREGUE e DEPLOYADA em 2026-08-08: a allowlist de fontes e o mapa de objetivo para

métrica âncora**, deixados por último de propósito por serem os únicos dois cuja configuração

errada degrada a veracidade do relatório e não a conveniência. Com eles os nove parâmetros com

ponto de chamada vivo ficam completos, e o patamar global do Super Admin foi exercitado pela

primeira vez de verdade (precedência padrão, global, agência, com um gestor de agência recebendo

recusa ao tentar escrever no global).

O defeito que esta fatia achou é o mais grave da família até aqui: o gate de honestidade, que é

o que reprova publicar número sem procedência, era chamado sem o mapa configurado e portanto

julgava sempre pela regra antiga, mesmo com outra configuração gravada. A agência configurava, a

tela gravava, e a publicação continuava decidindo pelo valor velho. Provado corrigido por um teste

que muda o veredito do mesmo relatório conforme a configuração.

Decisões declaradas, porque as duas leituras eram defensáveis: allowlist vazia da agência

significa "não acrescento nada", e a base sobrevive, de modo que a guarda nunca esvazia; allowlist

vazia no escopo global é escolha do Super Admin e vale como está; e o mapa da âncora só é aceito

inteiro, com o parcial recusado na escrita, para ninguém descobrir a configuração quebrada só na

hora de publicar. A validação de domínio passou a recusar sufixo público isolado, com a cobertura

declarada como parcial em vez de prometida como total.

**FATIA D ENTREGUE e DEPLOYADA em 2026-08-08: a ficha do cliente ganhou a sazonalidade e o modelo

de venda. Esta foi a única fatia que não construiu configuração nenhuma**: o backend das duas

já existia, correto e testado, e o que faltava era caminho para uma pessoa. É a família de

defeito mais cara deste projeto na forma mais pura, porque passa por qualquer suíte verde. Os dois

entraram juntos por medição: o modelo de venda estava na condição idêntica, e o cartão que o

entregou estava marcado como feito. O efeito a jusante de ambos foi provado no comportamento, não

no código: ligar a sazonalidade muda a base de comparação da publicação, e o modelo de venda decide

se os slots de resultado nascem.

Um defeito grave apareceu no review e vale como regra: a leitura do perfil falhava em silêncio

e o salvar mandava sempre o objeto inteiro. Juntos, faziam a rede cair, o formulário abrir com

valores padrão e o admin apagar os dados reais achando que salvou, com aviso de sucesso

confirmando a perda. Guarda que falha aberta em silêncio não guarda, e é a mesma família do cartão

{F8-15}.

E uma decisão tomada pela spec, não pela conveniência: o mês de pico era gravado, exibido e

nunca consultado pela composição. O DRS fecha a base sazonal com o mesmo período do ano

anterior, sem exigir o mês, então o campo não foi ligado à toa: passou a ser apresentado como

informativo. Controle que promete efeito e não tem é pior que controle ausente.

Fica nomeado como não feito: a mesma regra que impede sazonalidade ligada sem mês existe na

rota, mas não no banco, pois pôr a restrição lá exigiria migration no outro repositório e não

entrou nesta fatia.

Aceite (H1): Dado o conjunto de parâmetros declarado no Inventário, Quando cada um é

percorrido, Então cada parâmetro tem origem em configuração e tela de edição no escopo declarado,

E o número publicado no cartão do Inventário é igual ao número de parâmetros com caminho de edição

provado, E nenhum parâmetro declarado editável permanece como constante no código.

RF-REN-006, ADR-003, RNF-SEG-001 (caminho do leitor), RN-011. Cria a role reports_reader com GRANT de SELECT apenas em report, snapshot e comment (não no schema inteiro, que exporia rascunho, artefato e metas), sem alcance a outra tabela do schema nem a outro schema, sem query pesada. Habilita ROW LEVEL SECURITY nessas três tabelas e cria a policy PERMISSIVE do reports_reader que libera SÓ linhas de relatório com status publicado e não expirado (e o snapshot e os comment ligados a elas), resolvidas pelo public_token; essa PERMISSIVE do leitor convive com a RESTRICTIVE por company_id do operador ({F6-04}), porque cada policy é escopada pela sua role.

Como verificar (teste primeiro): a role reports_reader lê report, snapshot e comment de um relatório PUBLICADO e não expirado (permitido); tentar ler um relatório em rascunho, um não publicado, um expirado e um de outra agência retorna ZERO linhas (a PERMISSIVE só libera publicado+vigente); tentar um INSERT/UPDATE (recusado), consultar outro schema (recusado) e ler uma quarta tabela do próprio schema como report_draft, artifact ou report_goal (recusado).

Aceite (H1): Dado o serviço do leitor público, Quando ele resolve um link, Então usa a role reports_reader com SELECT apenas em report, snapshot e comment e uma policy PERMISSIVE que só devolve linhas de relatório publicado e não expirado, E não devolve rascunho, relatório não publicado, expirado ou de outra agência, E não tem permissão para escrever nem para ler report_draft/artifact/report_goal ou qualquer outro schema do Hub.

RF-REN-010. Link revogado ou expirado mostra página brandada com a marca da agência, sem conteúdo do relatório.

Como verificar (teste primeiro): abrir um link revogado e um expirado; confirmar página brandada e ausência total do conteúdo do relatório.

Aceite (H1): Dado um link revogado ou expirado, Quando o cliente o abre, Então vê uma página brandada com a identidade da agência e a mensagem para pedir novo link, E nenhum conteúdo do relatório é exibido.

RNF-SEG-005. Referrer-Policy: no-referrer, assets same-origin, token mascarado em log, resolução token para snapshot no-store.

Como verificar (teste primeiro): inspecionar os headers de resposta do leitor; conferir ausência do token cru em log de acesso.

Aceite (H1): Dado o leitor público, Quando ele serve uma página, Então envia Referrer-Policy: no-referrer e não registra o token cru em log, E os assets são servidos same-origin.

RNF-PERF-001. Página servida do cache; resolução token para snapshot sem varredura custosa.

Como verificar (teste primeiro): medir tempo de resposta de um link já publicado com cache quente; confirmar ausência de query pesada no caminho.

Aceite (H1): Dado um link já publicado, Quando o cliente o abre, Então a página responde a partir do cache sem query pesada, E a resolução token para snapshot não faz varredura custosa.

RNF-DISP-001. Leitor público e container de parse isolado têm deploy independente da fila de release do Hub; o chrome e a composição in-process acompanham a fila.

Como verificar (teste primeiro): publicar uma correção no leitor ou no container de parse sem passar pelo pipeline de release do chrome do Hub.

Aceite (H1): Dado uma janela em que a fila de release do Hub está congelada, Quando é preciso subir uma correção no leitor público ou no container de parse, Então ela sobe sem depender do deploy do Hub. O leitor tem disponibilidade maior que o painel e não há SLA contratual por ser ferramenta interna (DRS J.4).

FECHADO em 2026-08-08, mergeado e deployado. A declaração entrou na camada que já decide título

e metadados da página pública, sem tocar o renderizador compartilhado, que serve também o preview

do compositor e o PDF. Provado em produção, não só no código: relatórios publicados reais servindo

a declaração, e o limite de taxa do leitor intacto depois do rebuild.

A cobertura foi construída, não herdada: os relatórios publicados reais exercitam só 6 dos 16

tipos de bloco, então a verificação montou uma amostra com os 16 e mediu transbordo horizontal em

cada um. Testar só o que por acaso existe já deixou defeito passar neste projeto.

Acordar as regras revelou defeito novo, como previsto: o botão de comentar sobrepõe o título

em três tipos de bloco quando não há sobretítulo e o texto é longo. Estava invisível porque o

celular nunca renderizava em largura real. Fica em cartão próprio, por viver em outro arquivo.

E confirmou CSS morto: cinco classes de tela estreita que nenhum caminho emite, das quais

quatro sem nenhum aviso no código. Regra escrita e nunca executada é hipótese, não comportamento.

Achado de infraestrutura corrigido no mesmo deploy: o segredo da rota interna de configuração

tinha sumido do arquivo de ambiente em disco, sobrevivendo apenas injetado no container antigo,

o rebuild seguinte o teria perdido. Restaurado do template versionado e conferido contra a outra

ponta antes de gravar.

Cartão novo, defeito MEDIDO em 2026-08-05 durante a correção do {F7-04}. O documento servido pelo leitor não emite a declaração de viewport, então o navegador de celular assume uma largura fictícia de cerca de 980 pixels e todas as regras de estilo escritas para telas estreitas ficam adormecidas. Ou seja: o cuidado de desenho para celular existe no código e nunca chegou a nenhum cliente. Só apareceu porque uma verificação foi olhar a página com largura real de telefone; a suíte nunca pegaria, porque teste sem navegador não tem viewport.

RF-REN-006, RNF-USAB (leitura em celular). A página pública é o que o cliente da agência abre, e boa parte abre no telefone.

O que implementar: o documento passa a declarar o viewport como o padrão da web manda; e, com as regras de tela estreita finalmente ativas, revisar cada uma delas contra um telefone de verdade, porque nenhuma nunca foi exercitada de fato (uma regra escrita e nunca executada é uma hipótese, não um comportamento).

Como verificar (teste primeiro): abrir um relatório publicado num telefone de verdade, ou num navegador com largura de telefone e viewport respeitado, e confirmar que o desenho estreito acontece; conferir bloco a bloco que nenhum deles quebra, transborda na horizontal ou fica ilegível.

Aceite (H1): Dado um relatório publicado aberto em tela de celular, Quando a página carrega, Então o desenho para tela estreita é aplicado de fato, E nenhum bloco transborda na horizontal nem fica ilegível.

FECHADO em 2026-08-08, mergeado e deployado. Oito classes removidas, uma mantida com dono. A

prova é a inversa do normal: a página publicada não pode mudar, e o corpo do HTML servido saiu

byte a byte idêntico nos dois relatórios reais, com a única diferença ficando dentro do bloco de

estilo.

A medição respondeu as duas perguntas, não só a primeira. Além de "ninguém emite", cada classe

foi conferida contra o DRS para saber se era promessa de requisito pela metade (nesse caso o

defeito seria a peça faltando, não o estilo sobrando, e remover seria desfazer trabalho). Das

cinco nomeadas, todas eram código morto; a varredura achou mais três (do bloco de

confiabilidade, cujo emissor foi retirado de propósito e o estilo ficou esquecido) e **uma que não

era morta**, mantida com exceção que agora tem cartão próprio, o {F5-09}.

O artefato durável desta fatia não é a remoção, é a varredura, que reprova quando aparece

classe sem emissor. Ela nasceu com o mesmo defeito que esta série vem catando, dentro dela mesma:

não descia em subpastas, então um emissor futuro produziria um "sem órfãs" falso. Corrigido antes

do merge, com o caso que prova.

Achado que virou cartão próprio: uma das classes removidas vinha do mockup aprovado, que

desenha e-mail cru do visitante na página pública, contra requisito escrito. Ver {F5-08}.

Cartão novo, medido em 2026-08-08 durante a verificação do {F5-06}. O estilo do leitor tem

cinco classes que nenhum caminho do produto emite: a grade de criativos, e as quatro do rodapé

de assinatura (assinatura, dados da assinatura, marca d'água e nota privada). Só uma delas traz

aviso no código; as outras quatro parecem comportamento vigente para quem lê. Regra escrita e

nunca executada é hipótese, não comportamento, e ela custa caro de duas formas: dá impressão falsa

de cobertura a quem vai mexer no desenho, e some no meio das regras que valem de verdade.

RNF-MANUT-002, RNF-MANUT-003.

MEDIR ANTES DE REMOVER: para cada uma, confirme que nenhum caminho a emite hoje e decida se

ela era promessa de requisito que ficou pela metade. Se for promessa pendente, o defeito é a peça

faltando, não o estilo sobrando, e aí o cartão vira outro. Remover regra que alguém ia usar amanhã

é desfazer trabalho.

Como verificar (teste primeiro): varredura que confronte as classes declaradas no estilo com as

efetivamente emitidas por algum caminho, e que reprove quando aparecer classe nova sem emissor;

e a página publicada continuando idêntica, bloco a bloco, depois da remoção.

Aceite (H1): Dado o estilo do leitor, Quando a varredura roda, Então toda classe sem emissor é

listada, E as cinco já conhecidas aparecem nominalmente, E nenhuma foi removida sem antes se

confirmar que não era requisito pendente, E a página publicada não muda.

FECHADO em 2026-08-08, nas três cópias (a fonte no workspace e as duas servidas em produção),

com backup antes e o site conferido no ar servindo já o texto corrigido. Sem deploy: as cópias

servidas foram corrigidas direto, e a fonte junto, para o próximo deploy não trazer o defeito de

volta.

A decisão veio do próprio requisito, e é a parte que vale guardar: o RF-ANL-004 **não proíbe a

marca d'água**, proíbe o e-mail cru, e já declara o que deve aparecer no lugar (identificador

opaco: nome quando a pessoa está logada, "visitante" quando não). Ou seja, o mockup contradizia

uma spec que tinha a resposta escrita. Não houve escolha de produto a fazer nem escalada a fazer;

houve requisito a ler. Trocar o conteúdo foi o certo, remover o bloco teria descartado

comportamento que a spec pede.

A varredura das outras dezesseis telas achou e-mail em quatro, e nenhuma viola: as telas do

operador e da agência são autenticadas, não são HTML público; o campo do formulário é a própria

pessoa digitando o endereço dela; e a menção dentro de um comentário é conteúdo escrito por

usuário, não o sistema expondo terceiro. Fica registrado, de baixa prioridade e sem cartão, que

menção por e-mail dentro de comentário pode merecer tratamento um dia.

Cartão novo, confirmado em 2026-08-08 na verificação do {F5-07}. O mockup da página pública

ainda mostra "acessado por" seguido do endereço de e-mail do visitante, em duas cópias do arquivo.

RF-ANL-004 proíbe isso explicitamente no HTML público. O produto está certo (nunca foi

construído assim), mas o mockup é o guia visual de toda tela deste projeto: enquanto ele

desenhar aquilo, alguém vai reconstruir um dia, de boa-fé, achando que está seguindo o desenho

aprovado.

RF-ANL-004, RNF-LGPD-001.

O que implementar: corrigir o mockup nas duas cópias para não exibir identificação pessoal do

visitante, e conferir se outras telas do mockup trazem o mesmo tipo de promessa que a spec

nega. Achado assim raramente vem sozinho.

Como verificar (teste primeiro): varrer o mockup por endereço de e-mail e outros dados

pessoais desenhados, e confirmar que nenhuma tela promete o que um requisito proíbe.

Aceite (H1): Dado o conjunto de telas do mockup aprovado, Quando ele é percorrido, Então

nenhuma exibe dado pessoal de visitante que RF-ANL-004 proíba, E nenhuma promete comportamento que

um requisito do DRS negue.

Cartão novo, nascido de uma exceção nomeada em 2026-08-08. A limpeza do {F5-07} manteve, com

razão, a classe do desenho de iniciais do logo: ela não é código morto, é promessa adiada de

propósito desde o {F7-04}, porque o contrato de identidade não carrega o nome da agência para

derivar a inicial. Só que uma exceção sem cartão vira permissão permanente, e esta já sobreviveu a

duas fatias como comentário no código.

RF-ADM-004.

O que implementar: ou o contrato de identidade passa a carregar o nome da agência e o desenho

de iniciais entra como alternativa para quem não tem logo, ou se decide que ele não vai existir e

a classe sai junto com a decisão registrada. O que não pode é seguir como intenção sem dono.

Como verificar (teste primeiro): uma agência sem logo cadastrado abre a página pública e o

topo mostra o desenho de iniciais com a inicial certa; ou, na outra decisão, a varredura de estilo

sem emissor deixa de precisar de exceção.

Aceite (H1): Dado uma agência sem logo cadastrado, Quando a página pública é aberta, Então o

topo apresenta a alternativa decidida, E a varredura de estilo não carrega mais exceção sem dono.

**FECHADO em 2026-08-08 pela decisão DESCARTAR, medida contra o próprio RF-ADM-004, não escolhida

por gosto. O H1 do requisito (bloco 6, RF-ADM-004) exige exibir logo e cor da agência quando a

agência TEM identidade definida, e que nenhuma marca de outra agência apareça**, e não exige

nenhum desenho alternativo para quando a agência não tem logo. A própria nota de violação do

requisito é explícita: "viola-se este requisito se a página pública de um cliente da agência A

exibir marca de OUTRA agência ou marca genérica QUANDO A TEM IDENTIDADE DEFINIDA". Sem logo não é

esse caso. E a cláusula "nenhuma marca aparece" já foi VERIFICADA passando sem chip nenhum no

{F7-04}: "Sem logo, nada quebra; logo inválido é descartado", com layout idêntico a antes, sem buraco

e sem placeholder vazio, decisão deliberada registrada no próprio BLOCK_REGISTRY.hero. Busca no

DRS inteiro (RF, RN, Ap, jornadas) por "iniciais"/"chip"/"initial" não achou nenhuma outra menção,

a promessa nasceu só do comentário do código, nunca da spec.

O que saiu: a regra .r-hero-logo-chip de src/render-css.mjs (nunca teve emissor em nenhum

.mjs do pacote, em nenhuma das 3 superfícies que compartilham o mesmo render.mjs/

render-blocks.mjs), o comentário do BLOCK_REGISTRY.hero que prometia o fallback, e a entrada

r-hero-logo-chip do PENDING_REQUIREMENT_ALLOWLIST em test/render-css-coverage.test.mjs, porque a

allowlist volta a ficar vazia, mecanismo genérico preservado pra uma futura promessa real.

Prova de que a página não muda: HTML emitido por renderForReader/renderForPreview/

renderForPdf para o mesmo documento, com e sem logo, é byte-idêntico antes/depois fora do

<style> inline (só a regra CSS órfã sai do bloco de estilo; nunca apareceu como atributo

class= em nenhuma das duas versões). Suíte 1294/1299 verdes, as 3 falhas são de ambiente

(ERR_MODULE_NOT_FOUND em ingest-server/reader-server, pré-existentes, idênticas ao baseline

antes da mudança). Branch feat/f5-09-iniciais-logo (modularreports-dev, commit e4c5542),

pushada, sem merge ainda.

ENTREGUE em 2026-07-29, com deploy e validação em produção. O dono decidiu fazer a integração agora ({Q7} do Questionário). Migration aditiva no ModularHub ampliou a lista de módulos permitidos de 11 para 12 valores, semeou o módulo reports nas 4 agências existentes sempre DESLIGADO, e o gatilho de agência nova passa a semear desligado também. O catálogo espelho em código do Hub recebeu o módulo e os 8 slugs de permissão reports.*. Achado que salvou o card: a rota que liga e desliga módulo faz atualização, não criação, então sem o preenchimento prévio o botão do super admin falharia em toda agência já existente. Provado em produção pelo caminho real: o módulo aparece na lista, liga e desliga por HTTP autenticado, e os 11 módulos antigos ficaram com exatamente os mesmos estados.

RF-ADM-001; artefato ART-MIG-01. Cunhar o module_key novo reports: migration que adiciona o literal reports à restrição CHECK da tabela de entitlements de módulo do Hub, mais a entrada reports (rótulo "Relatórios", não core) no catálogo de módulos em código. Não reusa o módulo results. As tabelas de dados já existem (F1b).

Como verificar (teste primeiro): após a migration, uma Company pode receber o entitlement reports; nenhuma Company existente recebe o módulo ligado automaticamente; o catálogo de módulos em código lista reports.

Aceite (H1): Dado o Hub sem o módulo reports, Quando a migration de registro roda, Então o literal reports está na CHECK de módulos válidos e no catálogo de módulos em código, E nenhuma Company recebe o entitlement ligado por default.

RF-ADM-001. Entitlement reports per-Company, desligado por default, ligado pelo Super Admin.

Como verificar (teste primeiro): criar uma Company nova e confirmar que nenhuma rota/menu do Reports aparece; ligar o entitlement pelo painel do Super Admin e confirmar que a entrada aparece sem novo deploy.

Aceite (H1): Dado uma Company recém-criada, Quando ninguém ligou o entitlement reports, Então nenhuma rota, menu ou atalho do ModularReports aparece para os usuários dessa Company, E ligar o entitlement no painel do Super Admin passa a exibir a entrada do Reports sem novo deploy.

RF-ADM-002; artefato ART-ACS-01. Sem papel novo; slugs de permissão reports.* registrados no catálogo de permissões em código do Hub (defaults por papel mais metadados de capability), não numa tabela nova; override por usuário reusa a concessão de capability existente.

Como verificar (teste primeiro): o catálogo em código lista todas as permissões do Reports com prefixo reports.; nenhum papel novo aparece na lista de papéis do sistema; nenhuma tabela nova de permissões foi criada.

Aceite (H1): Dado o catálogo de permissões do Hub, Quando o módulo reports é instalado, Então todas as permissões do Reports têm slug com prefixo reports. registrado no catálogo, E não existe nenhum papel novo criado exclusivamente para o Reports.

RNF-SEG-001 (caminho do operador). Todas as tabelas do schema com RLS RESTRICTIVE por company_id para os usuários de agência autenticados, REVOKE ALL, helpers SECURITY DEFINER com search_path fixado. Esta RESTRICTIVE por company_id é escopada às roles dos usuários de agência e NÃO afeta a policy PERMISSIVE do reports_reader criada em {F5-01} (o leitor público não tem company_id de sessão e é liberado por token, não por company): as duas convivem, cada uma na sua role.

Como verificar (teste primeiro): um usuário da agência A consulta as tabelas do Reports e só recebe linhas de A; tentar contornar por FK cross-schema falha; confirmar que habilitar a RESTRICTIVE do operador não zera a leitura do reports_reader de um relatório publicado (a PERMISSIVE do leitor continua valendo).

Aceite (H1): Dado um usuário da agência A, Quando ele consulta qualquer dado do Reports, Então só recebe registros com company_id de A, E nenhuma FK cross-schema contorna esse escopo, E a leitura do reports_reader de um relatório publicado segue funcionando após a RESTRICTIVE do operador entrar.

RF-ADM-012; artefato ART-AUD-01. Toda ação relevante grava evento no log de auditoria do Hub com event_type prefixado reports., por um ponto único (o helper de auditoria do Hub), gravando valor anterior e valor novo quando altera estado; append-only por RLS; o log de republicação (RF-PUB-010) deriva desses eventos.

Como verificar (teste primeiro): publicar, republicar, revogar e encerrar cliente geram evento no log com antes e depois quando aplicável; buscar no código confirma um único ponto de escrita de auditoria; nenhum evento contém dado pessoal cru.

Aceite (H1): Dado qualquer ação de publicar, republicar, revogar ou encerrar cliente, Quando ela é executada, Então um evento com event_type iniciado por reports. é gravado no log do Hub com valor anterior e novo quando aplicável, E não há caminho de escrita de auditoria fora do ponto único.

RF-ADM-014, ADR-002. Menu e chrome próprios, não usa o menu lateral do Hub; entrada por item de menu do Hub, atalhos e endereço direto; mesma sessão.

Como verificar (teste primeiro): logado no Hub com o módulo ligado, clicar na entrada do Reports abre chrome próprio sem novo login; acessar o endereço direto também resolve na mesma sessão.

Aceite (H1): Dado um usuário logado no Hub com o módulo reports ligado, Quando ele clica na entrada do Reports, Então abre o chrome próprio do Reports (menu próprio, não o menu do Hub) na mesma sessão sem novo login, E o endereço direto do Reports também resolve na mesma sessão.

RNF-MANUT-002. Chrome do Reports carrega sob demanda; o white-label runtime do Hub não pinta o chrome do Reports.

Como verificar (teste primeiro): medir o bundle do Hub sem o Reports carregado; confirmar que o chrome do Reports só entra na rede ao navegar para ele.

Aceite (H1): Dado o bundle do Hub, Quando o usuário não navega para o Reports, Então o código do chrome do Reports não é carregado, E navegar para o Reports carrega o grupo de rotas sob demanda.

RF-ADM-003. Admin da agência gerencia (criar, editar, desativar) só os usuários da própria agência.

Como verificar (teste primeiro): um admin da agência A cria, edita e desativa usuários de A; tentar listar ou alterar usuário de outra agência é recusado.

Aceite (H1): Dado um admin da agência A, Quando ele gerencia usuários, Então consegue criar, editar e desativar usuários apenas da agência A, E não enxerga nem altera usuários de qualquer outra agência.

FECHADO em 2026-08-05, mergeado e DEPLOYADO em produção nas três superfícies (cabeçalho do módulo, leitor público e PDF). A cor da agência já passava nas duas pontas; o logo não aparecia em nenhuma, e essa era a metade que o cartão dava como pronta. Três causas, todas medidas antes de qualquer conserto: o cabeçalho do módulo não usava o componente de logo do Hub, apesar de o comentário do próprio arquivo alegar que reusava; o serviço do leitor entregava ao renderizador só a cor; e o retrato imutável da publicação nunca copiava o logo da agência, então o leitor não teria de onde tirá-lo mesmo se pedisse. Colateral corrigido junto: o renderizador nunca repassava a identidade a bloco nenhum, e a folha de estilo já previa o espaço do logo havia tempo, sem nunca ter sido usada. Verificado com olhos nas duas pontas, na mesma agência real: cabeçalho e gaveta mobile com a marca certa, e a página pública anônima em tela grande e estreita, publicada pelo caminho real de publicação e com o retrato escrito pela função de verdade. A cláusula "nenhuma outra marca aparece" passa. Sem logo, nada quebra; logo inválido é descartado. Retratos publicados antes da mudança seguem intocados, como manda a imutabilidade.

Dois defeitos que só apareceram porque alguém foi olhar, e que teriam passado por suíte verde: o logo sumia por completo na página pública abaixo de 1100px, escondido por uma regra antiga (reprovado pelo QA e corrigido: agora empilha abaixo do texto); e uma regra genérica de imagem vencia a do logo por especificidade, de modo que o teto de tamanho nunca funcionou, hoje o tamanho é medido na tela, não declarado no CSS. O PDF, que também nasceu sem o logo, entrou na mesma fatia (RF-REN-009, imagem embutida, sem busca de rede) e foi conferido página a página, com e sem logo.

Não exercitado, e nomeado: o teto de tamanho menor abaixo de 600px não pôde ser disparado porque o documento do leitor não declara viewport, o que mantém adormecidas todas as regras de tela estreita. Isso é o cartão {F5-06}, não desta fatia.

Contexto da medição anterior. O motivo antigo (a página pública só nasceria na Fatia 9) caiu: a Fatia 9 entregou e um relatório real foi publicado e aberto sem sessão. Com as duas pontas finalmente mensuráveis na MESMA agência (uma agência real, com logo e cor já cadastrados), o resultado é: a cor da agência passa nas duas pontas; o logo não aparece em nenhuma. No chrome do operador, o cabeçalho do próprio módulo mostra um ícone genérico e o nome do produto, enquanto o painel principal do Hub troca o ícone corretamente na mesma sessão e com a mesma empresa ativa; o dado do logo chega certo pela sessão, então é fiação faltando no cabeçalho do módulo, não dado ausente. Na página pública, o documento servido não tem imagem nenhuma, nem o desenho de iniciais que a folha de estilo já prevê: o serviço do leitor entrega ao renderizador só a cor da identidade, nunca o logo. A cláusula "nenhuma outra marca aparece" passa nas duas pontas. Fecha quando o logo da agência aparecer no cabeçalho do módulo e na página pública, com as mesmas duas pontas conferidas por olhos na mesma agência.

RF-ADM-004. Logo e cor da ficha da Company brandizam chrome do operador e link público.

Como verificar (teste primeiro): agência A com logo e cor definidos; abrir o chrome e publicar um link mostram a marca de A; nenhuma outra marca aparece.

Aceite (H1): Dado a agência A com logo e cor definidos na ficha da Company, Quando um operador de A usa o Reports e publica um link, Então o chrome do operador e a página pública exibem o logo e a cor de A, E nenhuma marca de outra agência aparece.

RF-CMP-001. Coleta cliente, período e tipo (template); não avança sem os dois primeiros.

Como verificar (teste primeiro): selecionar cliente, período e tipo e avançar cria o rascunho vinculado; tentar avançar sem cliente ou período é bloqueado.

Aceite (H1): Dado o wizard aberto, Quando o operador seleciona cliente, período e tipo e avança, Então o rascunho é criado vinculado a esse cliente e período com o template escolhido, E não é possível avançar sem cliente e período preenchidos.

RF-CMP-002, Ap.1. Coleta KPI principal, a direção (objeto do Ap.1: objetivo_campanha no enum fechado, objetivo/tese, público, decisão alvo, tom, enfatizar, evitar, blocos preferidos, lacunas conhecidas), destaques, identidade; KPI, objetivo_campanha, tese e decisão alvo obrigatórios.

Como verificar (teste primeiro): preencher os campos e avançar grava a direção no rascunho; tentar avançar sem KPI principal, objetivo_campanha, tese ou decisão alvo é bloqueado; um campo da direção não grava nem altera nenhum dp: em data_points; a direção não introduz um tipo de bloco fora do Ap.3.

Aceite (H1): Dado o passo de briefing, Quando o operador preenche KPI principal, a direção (com o objetivo da campanha no enum, a tese e a decisão alvo) e a identidade e avança, Então o objeto de direção fica gravado no rascunho e disponível ao pipeline como instrução tipada, E o KPI principal, o objetivo_campanha, o objetivo (tese) e a decisão alvo são obrigatórios para avançar, E nenhum campo da direção grava ou altera um dp:.

RF-CMP-017. Monta e mostra ao operador o prompt de instrução que será enviado à IA (a direção compilada em texto), com o catálogo de pontos de dado somente leitura como contexto (referenciável só por metric_id, nunca digitável nem colável); o operador revisa, edita e adiciona detalhe, e só confirma quando pronto. Dependência: {F8-02}.

Como verificar (teste primeiro): preencher a direção e chegar ao prompt mostra o texto de instrução montado e editável e o catálogo de pontos de dado em modo somente leitura; tentar digitar ou colar no catálogo é bloqueado; editar o prompt não cria nem altera nenhum dp: em data_points; tentar compor sem confirmar o prompt é bloqueado.

Aceite (H1): Dado a direção pronta, Quando o operador chega ao prompt, Então o sistema mostra o prompt de instrução montado e editável e o catálogo de pontos de dado em modo somente leitura, E a composição só dispara após o operador confirmar, E nenhuma edição do prompt cria um dp: nem torna o catálogo de pontos de dado editável.

RF-CMP-019. Uma chamada única à cadeia gratuita (RF-CMP-011) transforma nota solta do operador mais o catálogo de dp:/blocos disponíveis num objeto de direção editável; opcional por uso (a direção manual basta), disponível desde a Fatia 1, fora do teto de 60s. Dependência: {F8-02}, {F1-07} (gateway de IA reusado).

Como verificar (teste primeiro): acionar o compilador com uma nota solta devolve um objeto de direção (nunca narrativa nem número) editável pelo operador; pular o compilador e preencher a direção manualmente em {F8-02} basta para avançar.

Aceite (H1): Dado uma nota solta do operador e o catálogo de dp: e blocos, Quando o operador aciona o compilador, Então uma chamada à cadeia gratuita devolve um objeto de direção editável (nunca narrativa nem número), E o operador revisa e confirma antes de compor, E o passo é opcional (a direção manual do {F8-02} basta sem ele).

RF-CMP-003. Preview do que a IA entendeu mais "o que não achei" em destaque.

Como verificar (teste primeiro): artefato com um dado esperado pela intenção mas ausente faz esse dado aparecer na lista "o que não achei", não some.

Aceite (H1): Dado artefatos processados no passo de dados, Quando a leitura da IA termina, Então o operador vê um preview do que a IA entendeu e uma lista explícita "o que não achei", E um dado esperado pela intenção mas ausente nos artefatos aparece nessa lista, não some em silêncio.

RF-CMP-004. Composição proposta bloco a bloco com origem de cada número; confirmar abre no compositor.

Como verificar (teste primeiro): cada bloco proposto exibe a origem de seus números; confirmar abre o rascunho no compositor com esses blocos.

Aceite (H1): Dado a leitura concluída, Quando o wizard propõe a composição, Então cada bloco proposto exibe a origem de cada número (artefato e célula ou campo), E ao confirmar, o rascunho abre no compositor com esses blocos.

RF-CUR-001. Editar texto, reordenar e esconder blocos; bloco escondido não vai ao snapshot.

Como verificar (teste primeiro): editar, reordenar e esconder um bloco persiste; o bloco escondido não aparece no preview nem no snapshot publicado depois.

Aceite (H1): Dado um rascunho aberto no compositor, Quando o operador edita o texto de um bloco, reordena e esconde outro, Então as mudanças persistem no rascunho, E um bloco escondido não aparece no preview nem irá para o snapshot.

RF-CUR-002. Regenerar um bloco com instrução nova mantém proveniência e não altera os demais.

Como verificar (teste primeiro): pedir regenerar um bloco com instrução ("foco no público 25 a 34") recompõe só aquele bloco mantendo dp: dos números; os demais blocos permanecem intactos.

Aceite (H1): Dado um bloco no compositor, Quando o operador pede regenerar com uma instrução, Então só aquele bloco é recomposto pela IA mantendo a proveniência dos números, E os demais blocos permanecem intactos. Regenerar um bloco é resposta imediata, síncrona (DRS J.4).

FECHADO em 2026-08-08, mergeado e deployado, provado em produção: criativo inserido pelo

compositor, relatório publicado, e a imagem aparecendo no link público real que o cliente abre.

Link revogado e tudo limpo depois.

A fatia não tinha um defeito, tinha cinco, e nenhum era dela. Ela foi a primeira coisa a gerar

um criativo em produção, e por isso exercitou pela primeira vez tudo que dependia disso: a ação não

existia em camada nenhuma (o cartão dizia que faltava só exercitar); a rota do preview **não tinha

como servir a imagem**, o que faria a segunda metade do aceite falhar mesmo com rota e botão

prontos; a guarda que protege a referência do arquivo estava escrita, exportada e **ausente da

lista de gates; a gravação da composição lia o rascunho, chamava a IA e gravava sem reler nem

travar**, perdendo em silêncio o bloco que o operador acabara de inserir; e o segredo que liga o

proxy de imagem do leitor nunca tinha sido provisionado desde a fatia que o criou. Todos

invisíveis porque nunca houve um criativo em produção.

Duas regras nasceram no DRS antes do código, porque a fatia as exigia: o bloco inserido pelo

operador sobrevive a qualquer reescrita do conjunto (gravar composição deixou de ser "substitua

tudo" e virou junção com trava), e a legenda entra na disciplina de número, com o perímetro

derivado da ficha de campos editáveis e não de lista à mão, foi lista à mão que deixou a

legenda passar até aqui.

E um bloqueio de entrega que três frentes não viram: a branch não buildava. A checagem de

tipos passava, a construção da imagem de produção falhava, e a diferença entre as duas só apareceu

quando alguém precisou do artefato de verdade. Ver a lição registrada em memória.

Deixado fora de propósito, com cartão próprio: imagem vetorial é recusada pela rota nova

({F8-19}) e a eliminação de dados pessoais ainda não alcança arquivo ({F8-20}). Os dois tinham

superfície zero até esta fatia, e é ela que acaba com o zero.

RF-CUR-003. Inserir imagem de anúncio como bloco de mídia, referenciando o asset por asset_id+sha256.

O MOTIVO ANTERIOR ESTAVA ERRADO, medido em 2026-08-08. O cartão dizia que faltava só alguém

exercitar o aceite. Não falta: não existe onde clicar. Uma verificação percorreu o compositor

em produção, inventariou todos os controles da tela e não achou nenhum de inserir mídia; varreu o

código do painel e não achou nenhuma chamada de envio de arquivo fora da ingestão de artefatos; e

varreu as rotas e descobriu que não existe nenhuma que CRIE bloco. As rotas de bloco todas

operam sobre um bloco que já precisa existir, e quem cria bloco é só a composição de IA.

A rota de envio do arquivo existe e funciona (provada ao vivo: devolve identificador e resumo

criptográfico corretos, o resumo confere, e nunca devolve endereço nem a imagem embutida). O que

não existe é o caminho entre ela e o rascunho. **É a sexta ocorrência da família "peça pronta,

nunca ligada" neste projeto**, e a mais nítida: o único lugar do repositório que aciona o

armazenamento é um teste, chamando a função direto, sem passar por rota nem por tela.

O que falta construir: uma rota que crie o bloco de mídia a partir do identificador e do

resumo, e o controle no compositor que envia o arquivo e chama essa rota. Atenção ao que isso

significa no desenho: hoje todo bloco nasce da composição de IA, com proveniência. Um bloco

inserido à mão é o primeiro que nasce sem esse caminho, e precisa passar pelos mesmos gates de

publicação que os demais.

Nota de 2026-08-02, CONFIRMADA em 2026-08-05 após uma volta em falso. O bloqueio de storage caiu de verdade com a {F15-02}: uma medição no meio do caminho desconfiou disso por ter consultado o serviço de armazenamento errado (a plataforma-mãe nunca usou aquele serviço, de nenhum módulo), e uma segunda medição no mecanismo real (sistema de arquivos sobre volume dedicado, já com arquivo real do módulo gravado nele) confirmou que o storage funciona. O que essa nota concluía sobre o motivo do cartão ("segue aberto por UM motivo só: ninguém exercitou o H1") está morto desde 2026-08-08, pela medição do parágrafo de cima: não é falta de exercício, é falta de construção. A parte da nota que continua de pé é só a do storage.

O DRS ganhou duas regras por causa deste cartão, publicadas em 2026-08-08 ANTES de qualquer código (Regra Zero). O planejamento desta fatia esbarrou em duas perguntas que o documento não respondia, e nenhuma das duas era detalhe de implementação. RF-CUR-010: hoje todo bloco nasce da composição e o caminho que grava a composição sobrescreve o conjunto inteiro; a partir do momento em que existe bloco inserido à mão, é preciso dizer o que acontece com ele quando o conjunto é gravado de novo. A resposta escrita é que o bloco do operador SOBREVIVE, com o preço declarado no próprio requisito (a gravação deixa de ser "substitua tudo" e vira junção) e com ordem e colisão já resolvidas ali, para não virarem decisão na hora. RF-CUR-011: a definição de "número exibido" do Ap.8 nomeava só o body_md, então uma legenda de criativo com número dentro publicaria sem origem sem violar requisito nenhum; o perímetro passou a ser derivado da ficha do Ap.3 (todo campo de texto editável pelo operador) em vez de uma lista mantida à mão. Atenção a uma armadilha do requisito novo: o critério de métrica é o MESMO do body_md, então "Criativo 3" (ordinal) NÃO reprova; endurecer só a legenda é violar RF-CUR-011, não cumpri-la. Provas em {TA-123} e {TA-124}.

Como verificar (teste primeiro): inserir um criativo adiciona um bloco de mídia ao rascunho e aparece no preview; o payload não guarda URL crua nem base64. As três cláusulas irmãs, que este cartão fecha junto e não depois: o payload referencia por identificador e hash ({TA-23}, reaberto em 2026-08-08 porque estava fechado sobre um gesto que não existe), o bloco do operador sobrevive a uma segunda gravação do conjunto ({TA-123}) e a legenda não publica métrica sem origem ({TA-124}).

Aceite (H1): Dado o compositor, Quando o operador insere um criativo, Então um bloco de mídia referenciando o asset por identificador e hash é adicionado ao rascunho, E o criativo aparece no preview.

FECHADO POR INTEIRO em 2026-08-10. A Fatia B (logo do cliente) foi mergeada nos dois repos

(5a89341 no pacote, ab86f02 no Hub) e deployada nas três superfícies: front, API e leitor. QA

PASS e review APPROVED.

A prova que fecha o cartão, e ela é a mais forte do dia: o QA alterou o rascunho **direto no

banco, contornando até a guarda da própria aplicação, e a página publicada continuou servindo o

logo antigo**. O retrato congelado é congelado de verdade, não por convenção de código. Junto disso:

duas marcas na página e exatamente duas imagens, sem sobreposição de caixas; proporção conferida

contra o arquivo (300 por 100 renderizando 3 para 1 em tela grande e em celular); retrato publicado

em 30/07, sem chave nenhuma de identidade, abrindo em 200; e o fluxo humano inteiro exercitado com

arquivo real, da prévia à publicação.

O que a Fatia B fechou além do próprio escopo: a rota do logo entrou sem a rejeição de

imagem vetorial que a rota de bloco de mídia aplica de propósito, não por decisão, mas porque a

guarda vive em quem chama e não havia como lembrar. Corrigido por reuso da mesma constante, com o

par de casos provado por HTTP real nas duas rotas. O review confirmou que **o terceiro caminho ainda

nasceria furado**, o que é a justificativa medida do {F8-19}.

Verificação de integração feita antes de publicar, e ela não era óbvia: a branch estava cinco

commits atrás da main, porque o {F8-25} mergeou no meio, e os dois tocaram o mesmo arquivo de rotas.

Depois do merge, a guarda de corrida do {F8-25} foi rodada contra a main mesclada: 13 sítios,

zero violações. Sem isso, uma escrita nova entrando sem trava passaria com os dois gates verdes,

porque cada um viu só o seu lado.

**METADE ENTREGUE em 2026-08-09 (Fatia A: cor e título), MERGEADA e DEPLOYADA. A metade do LOGO

dependia de {F8-21}**, hoje fechado. O cartão fechou PARCIAL de propósito, com a cláusula que

falta nomeada, porque placar menor e verdadeiro vale mais que placar redondo.

O defeito central era anterior ao controle novo, e é o que a fatia de fato consertou: o preview

não recebia identidade nenhuma e desenhava com um valor fixo. O operador curava vendo uma cor e

o cliente recebia outra. Depois do deploy, o preview passou a mostrar a cor real da agência **mesmo

sem nenhuma sobreposição configurada**.

Três defeitos foram revelados e consertados no caminho, nenhum previsto no cartão: uma segunda

consulta de leitura sem a coluna nova fazia a tela esquecer o que o banco tinha gravado; a

restrição do banco tinha buraco de lógica de três valores igual ao da validação no código, ou

seja, duas camadas que falham do mesmo jeito não são duas camadas; e a cor não aparecia no

compositor porque a montagem do preview descartava o invólucro que carrega a variável, embora a

página pública usasse o mesmo mecanismo com ele presente.

A ORDEM FOI INVERTIDA nesta fatia, e fica registrado. O plano desta fatia declarava, como passo

1, publicar no DRS e no Inventário as regras que ela exigia antes de qualquer código. A

construção foi despachada sem esse passo: o código ficou pronto e em gates, e o documento não sabia

dele. A revisão de código mediu a divergência e apontou. **A obra precedeu o documento aqui, e a

reconciliação veio depois, em 2026-08-09** (RF-CUR-004 endurecido, RF-CUR-012, RF-CUR-013, RN-020,

a coluna nova no Inventário e este cartão). Nada foi revertido; o que se corrigiu foi a ordem, e a

lição é que despachar construção sem despachar o passo zero deixa o bloqueio vivendo só na cabeça

de quem planejou.

O que a Fatia A entregou: sobreposição de identidade por relatório com conjunto de chaves

fechado em duas e restrição própria no banco (nunca misturada na do ajuste fino, RF-CUR-008

intocado); a precedência extraída para um ponto único chamado tanto pela publicação quanto pelo

preview; limpar a sobreposição remove a chave e nunca grava vazio; a seção de identidade na

coluna direita do compositor, com atalho de cores lido do catálogo e entrada livre de cor, nunca

lista fixa na tela; e o título do relatório editável em linha, que era peça pronta e

inalcançável fora do assistente.

O defeito maior que ela consertou não era o pedido do cartão: o preview **nunca resolvia

identidade nenhuma** e mostrava a cor padrão do renderizador, ou seja, o operador curava numa cor e

só descobria a cor real do cliente depois de publicar. Isso valia para todo relatório, com zero

sobreposição.

O que ela NÃO entregou, e por quê: o logo do cliente. Existe um portador de marca na página

publicada e ele carrega a marca da agência; pôr o logo do cliente ali apagaria a marca da agência,

que é o que {F7-04} construiu de propósito e o que RF-ADM-004 exige. O portador do cliente e o da

agência são separados desde o protótipo aprovado, e o da agência nunca foi construído: é

{F8-21}. Enquanto ele não existir, a Fatia B não começa.

RF-CUR-004, RF-CUR-012, RF-CUR-013, RN-020. Sobreposição por relatório, campo a campo, resolvida

por ponto único, congelada no retrato e rerresolvida na republicação.

Como verificar (teste primeiro): definir a cor pelo atalho e pela entrada livre reflete no

preview na mesma interação; limpar devolve a cor da ficha do cliente; publicar copia a cor para o

retrato e marca a procedência; editar a sobreposição depois de publicado não muda a página

publicada, e republicar muda mantendo o mesmo link; renomear o relatório pelo compositor persiste e

é recusado depois de publicado; preview e publicação devolvem a MESMA cor para o mesmo estado. Com

a Fatia B: a página publicada exibe o logo do cliente no portador do cliente e a marca da

agência no portador da agência, as duas ao mesmo tempo.

Aceite (H1): Dado um rascunho no compositor, Quando o operador define a cor de acento do

relatório, Então o preview passa a exibir essa cor na mesma interação e sem publicar, E publicar

copia essa cor para o snapshot, E limpar a sobreposição remove a chave em vez de gravar vazio, E

definir ou limpar um dos dois campos não altera o outro, E nenhuma chave fora do par fechado é

aceita em camada nenhuma, E quando o operador sobrepõe o logo do cliente a página publicada exibe

esse logo no portador do cliente e continua exibindo a marca da agência no portador da agência.

RF-CUR-005. Cada tipo de bloco declara no schema os campos editáveis; compositor só expõe esses.

Como verificar (teste primeiro): abrir a edição de um bloco só mostra os campos da whitelist; um valor numérico com proveniência não aparece como editável.

Aceite (H1): Dado um tipo de bloco com whitelist de campos editáveis, Quando o operador abre a edição desse bloco, Então só os campos da whitelist são editáveis, E campos fora da whitelist (por exemplo, o valor numérico com proveniência) não são editáveis à mão.

RF-CUR-006. Modo apresentação (tela cheia, navegação por passos), rótulo "rascunho", sem pins de comentário.

Como verificar (teste primeiro): entrar no modo apresentar abre tela cheia com o rótulo "rascunho"; sair volta ao compositor sem ter publicado nada.

Aceite (H1): Dado um rascunho no compositor, Quando o operador entra no modo apresentar, Então a apresentação abre em tela cheia com o rótulo "rascunho" e sem os pins de comentário, E sair do modo apresentar volta ao compositor sem ter publicado nada.

FECHADO em 2026-08-08 POR VERIFICAÇÃO, sem código novo. O comportamento já existia; o que

faltava era a prova da metade que o requisito realmente protege. Publicar por sessão humana já

tinha evidência de sobra nas fatias anteriores, e ninguém nunca tinha exercitado a recusa.

A metade decisiva, provada no caminho real: a identidade que o **próprio sistema usa

internamente** foi testada em três formas diferentes, e em nenhuma a publicação concluiu, com o

banco confirmando zero linha tocada. Não foi leitura de código: foi chamada de verdade contra

produção.

Um terceiro caso, que o cartão não pedia e mudou a leitura: por padrão os papéis operacionais

já vêm com a permissão de publicar, então "humano sem a permissão" só existe por revogação

explícita. A verificação criou um usuário real, revogou a permissão pelo mecanismo de administração

de verdade, teve a publicação recusada, e ainda conferiu que a sessão continuava funcionando, para

não confundir recusa de permissão com sessão quebrada. Usuário removido no fim.

Aspereza registrada, sem reprovar: um ator de serviço com identidade vazia derruba a consulta

de permissões com erro genérico em vez de uma recusa limpa. Nada publica, então não é furo; é

tratamento de erro a melhorar.

RF-CUR-007. Publicar exige sessão humana com a capability reports.publish; ator de serviço é recusado (reforça {F1-06}).

Como verificar (teste primeiro): tentar publicar via chamada de API com um ator sem reports.publish é recusado; publicar via sessão humana com reports.publish conclui.

Aceite (H1): Dado um rascunho pronto, Quando a publicação é acionada, Então ela só conclui a partir de uma sessão humana com a capability reports.publish, E qualquer tentativa de publicação por ator de serviço é recusada.

FECHADO em 2026-08-08 POR VERIFICAÇÃO, sem código novo. A composição responde na mesma chamada,

medido em produção: uma requisição, resultado completo no corpo, e o rascunho gravado dentro da

própria chamada. A tabela da fila assíncrona existe e está vazia, o que confirma o requisito

pelo lado de fora: ela segue reservada para evolução, não em uso.

A metade que costuma faltar foi provada de verdade, e não por leitura: um container descartável

com as chaves de IA quebradas fez os quatro provedores falharem de fato, e o operador recebeu

mensagem em linguagem humana, sem jargão, sem código de erro cru, dizendo que os números continuam

válidos e o que fazer em seguida. Falha explícita, nunca silêncio.

O que NÃO foi provado, e fica nomeado: o pixel do indicador de espera na tela. O caminho está

confirmado no código, e a caixa de falha usa exatamente os campos que a prova acima exercitou, mas

o ambiente de automação não conseguiu alcançar o último passo do assistente depois de oito

tentativas por caminhos independentes. É limitação de ferramenta, declarada em vez de maquiada.

RNF-PERF-002. A composição é síncrona in-process (10 a 30 s); o wizard mostra o wait com fail-loud enquanto processa. Uma fila assíncrona com estado persistido (report_job) é evolução, não V1.

Como verificar (teste primeiro): disparar uma composição mostra o wait no wizard e conclui de forma síncrona; uma falha da composição aparece explícita (fail-loud), não em silêncio.

Aceite (H1): Dado uma composição disparada no wizard, Quando ela roda, Então o wizard mostra o wait e devolve o resultado de forma síncrona, E uma falha aparece explícita ao operador. A fila assíncrona (report_job) fica reservada para evolução (DRS RNF-PERF-002).

RF-CUR-008. Dependência: {F8-01} (compositor). O operador ajusta os 4 steppers de token (paddingStep, gapStep, fontSizeStep, buttonAccentStep) por bloco (style_overrides) e por relatório (theme_overrides), sempre por índice de escala fechada com clamp aos limites; nunca CSS, HTML ou valor livre; o título nunca desce abaixo do corpo na escala de fonte; o acento nunca passa de hex, só degrau da rampa já validada AA.

Como verificar (teste primeiro): ajustar um dos 4 steppers muda o valor em passos dentro da escala com clamp; enviar uma chave fora do conjunto fechado é rejeitado pelo schema (additionalProperties:false); forçar buttonAccentStep num degrau abaixo de AA reprova o publish ou é ajustado por clamp de contraste; forçar um override que estoura o layout no render real mobile ou PDF reprova o publish.

Aceite (H1): Dado um bloco ou o relatório, Quando o operador ajusta uma das 4 propriedades, Então o valor muda em passos dentro da escala de tokens com clamp (nunca fora), E o publish é recusado se o buttonAccentStep resultar em contraste abaixo de AA ou se o override estourar o layout no render real mobile ou PDF, E nenhuma chave fora do conjunto fechado é aceita.

RF-CMP-020. Dependência: {F1-07}/{F1-08} (gateway de IA, cadeia gratuita). Decisão do dono ({Q5}, 2026-07-29): operação só com IA gratuita, mas com comunicação explícita ao operador e escalonamento ao admin. Quando composeWithFreeChain esgota a cadeia inteira (sinaliza explicitamente que todos os provedores falharam), nenhuma narrativa é entregue, o operador vê mensagem em linguagem humana (sem jargão nem código de erro cru) dizendo que os números continuam válidos e que dá para escrever à mão ou tentar depois, e um payload pronto para a Central de Notificações do Hub (messages.publish_notification) carrega o relatório, o horário e o motivo real por provedor. Entregue nesta fatia: a base determinística (o gateway captura o motivo real por tentativa em vez de descartá-lo; a camada de falha de composição classifica, monta a mensagem humana e o payload do admin, e dispara notifyComposeFailureAdmins contra o schema real; composeReport expõe tudo isso em narrativeFailure). Fora do escopo desta fatia (fica para quando o RBAC do Hub estiver montado, {F6}/{F7}): a tela do botão de um clique e a resolução de QUEM é o admin da agência (RF-ADM-002/RF-ADM-003); o ponto de ligação já está pronto e documentado no próprio módulo de falha de composição.

Como verificar (teste primeiro): simular a queda dos 4 provedores gratuitos confirma que nenhuma narrativa sai (narrativeText: null, aiOk: false) e que dataPoints/gaps continuam intactos; a mensagem ao operador não contém nenhum dos termos técnicos (código de falha interno, status HTTP cru, nome de variável de ambiente); o payload do admin contém o reportId, o horário e o motivo real de cada um dos 4 provedores; notifyComposeFailureAdmins contra o schema real do Hub (teste de integração, com credenciais lidas do ambiente e nunca persistidas) grava uma linha em messages.notifications por admin alvo, lida de volta com type='system_alert', origin_module='reports' e o link relativo certo.

Aceite (H1): Dado que a cadeia gratuita de IA falhou por completo durante uma composição, Quando o resultado chega ao operador, Então nenhuma narrativa é entregue (nem local nem de stub), E o operador vê uma mensagem em linguagem humana explicando o que aconteceu e o que fazer, sem jargão técnico nem código de erro cru, E os números do relatório continuam íntegros e disponíveis, E uma ação de um clique dispara um aviso ao admin da agência pela Central de Notificações do Hub com o relatório, o horário e os provedores que falharam e o motivo de cada um.

FECHADO em 2026-08-09, mergeado e deployado, provado em produção. O conserto é de uma linha: a

gravação parcial deixou de substituir a coluna inteira e passou a mesclar por chave.

A medição do conjunto mudou a leitura do defeito: cinco pontos gravam aquela coluna, e

apenas um estava quebrado. Os outros quatro já mesclavam corretamente. O defeito era o ímpar,

não a regra, e é por isso que ele sobreviveu tanto tempo: pela ordem que o assistente usa, nunca se

manifestava.

A pergunta que virou resposta, e não ficou como suposição: cruzando o registro de auditoria

contra o estado atual, dois rascunhos de fato perderam dado. Os dois eram fixtures de teste já

revogadas, e um terceiro candidato foi investigado e descartado por estar íntegro. **Nenhum

rascunho de cliente real foi atingido**, e isso é afirmação medida duas vezes, por frentes

diferentes, não estimativa.

A prova do aceite foi o gesto, não o teste: a verificação percorreu o assistente de verdade,

avançou uma etapa, disparou a pesquisa de mercado, voltou pela etapa anterior e salvou de novo,

que é exatamente o movimento que dispara o defeito. Sem o conserto, sete testes reprovam.

Limitação registrada, sem promessa falsa: só uma das três partes tem caminho de remoção

nominal. As outras duas se sobrescrevem, mas não se apagam. Nenhum requisito pede isso hoje, e o

comentário do código merece redação mais estreita para não sugerir cobertura que não existe.

Achado fora do diff, que virou o cartão {F8-25}: a mesma corrida de ler, chamar a rede e gravar

cego existe em outras duas rotas, ainda sem conserto. É a terceira ocorrência do padrão.

Cartão novo, defeito MEDIDO em 2026-08-05 durante a verificação da {F4-05}. A rota que salva o briefing do rascunho substitui a coluna inteira em vez de mesclar, então chamá-la depois da leitura dos artefatos, da pesquisa de mercado ou do prompt apaga silenciosamente o que aquelas etapas já tinham gravado. O defeito só apareceu porque uma verificação ponta a ponta chamou os passos fora da ordem feliz e perdeu o trabalho duas vezes; pela ordem que o assistente usa hoje, ele não se manifesta, o que é exatamente o que o torna perigoso (a próxima tela, o próximo salvamento automático ou o retorno a um passo anterior o acordam). É a assinatura de regressão silenciosa da casa: quem grava não declara o que remove.

RF-CMP-002, RF-ING-005, RF-ING-006.

O que implementar: a gravação parcial do briefing passa a mesclar por chave, preservando as chaves que não vieram na requisição; e quem precisar de fato apagar uma parte apaga aquela parte nominalmente, nunca por substituição total implícita.

Como verificar (teste primeiro): gravar a leitura dos artefatos, depois a pesquisa de mercado, depois o prompt, em qualquer ordem e em chamadas separadas, e confirmar que as três continuam no rascunho ao reler do banco; e confirmar que apagar uma parte nominalmente não toca as outras.

Aceite (H1): Dado um rascunho com leitura de artefatos, pesquisa de mercado e prompt já gravados, Quando qualquer uma dessas partes é salva de novo isoladamente, Então as outras permanecem íntegras no rascunho, E nenhuma chave do briefing é removida sem ter sido nomeada na requisição.

FECHADO em 2026-08-18, conferido NA TELA - o card nasceu com olhos e foi verificado com olhos.

As 10 faixas da tela de branding foram lidas em produção: nenhuma carrega número em ordem de byte

cru. A quota passou a dizer "no máximo 200 artefatos, 256 MB no total e 5000 páginas de PDF".

Corrigido na FONTE, não na tela: o texto sai do catálogo (que é o que a tela exibe) e é

derivado do próprio teto, então mudar o teto muda o texto. O valor da chave continua em bytes

- é o contrato da API, e há teste provando que não mudou.

A guarda por construção achou o irmão do defeito no mesmo commit: a faixa do limite de

requisições do leitor dizia "entre 1000 e 3600000 ms" (1 segundo e 1 hora, que ninguém lê assim).

Corrigida junto. A guarda percorre o catálogo INTEIRO procurando número de 7+ dígitos em qualquer

faixa - parâmetro novo com unidade ilegível nasce reprovado, sem ninguém lembrar de vir aqui.

Suíte 1631 verde; merge em main, deployado.

Cartão novo, visto na tela durante o deploy do {F8-18} em 2026-08-13, com olhos, não em teste.

O que acontece: a faixa recém-criada exibe o número em bytes (nove dígitos) imediatamente

acima de um campo cuja unidade declarada é megabyte. Quem opera lê dois números que parecem

incomparáveis e precisa fazer a conta de cabeça para saber se o valor que quer cabe.

Por que não foi consertado no deploy, e a decisão está certa: não era escopo daquela fatia, e

mexer em tela durante deploy de infraestrutura é como se estraga deploy. Virou cartão porque

cobrança sem dono some na próxima leitura. Foi assim que o {F8-50} nasceu.

É pequeno e é real: o {F8-18} existiu para que o limite parasse de ser peça que só aparece na

recusa. Um número que o operador não consegue comparar com o campo ao lado ainda é isso.

Como verificar (teste primeiro): a faixa é exibida na mesma unidade do campo que ela limita.

Aceite (H1): Dado um parâmetro com faixa, Quando o operador olha a tela, Então faixa e campo

falam a mesma unidade, E ele não precisa converter nada para saber se o valor cabe.

FECHADO em 2026-08-13, mergeado e em produção: pacote 1f044c1 antes do Hub 2aa4561, nessa

ordem por exigência do gate: o Hub lê o catálogo em tempo de execução por montagem do outro repo, e

a ordem inversa faria a tela dizer que os parâmetros não são graváveis **enquanto as escritas

funcionavam**.

O cartão errou num dos três fatos que afirmava, e o erro foi para melhor. Ele supunha que o corpo

era lido inteiro antes da decisão. Não era: a recusa já acontecia antes. O defeito real era

outro e mais perigoso: a guarda falhava aberta. Cabeçalho de tamanho ausente virava zero e

aprovava; ilegível virava valor não-numérico e, pela forma da condição, **pulava a verificação

inteira. A validação mediu que sete** formas de valor passavam pela guarda antiga e são recusadas

pela nova.

A faixa é por construção, e isso foi testado, não afirmado: a validação acrescentou uma entrada

nova ao catálogo real sem teto e a escrita foi recusada. Parâmetro novo nasce recusado, não

ignorado. A lista curada não teve como nascer aqui.

O limite de memória virou real neste deploy, que é por que o cartão não podia fechar antes: o

processo que atende todas as agências rodava sem teto nenhum e agora tem 2 GB. A validação rodou

o controle que a obra não tinha rodado (os mesmos 3 GB sem o limite passam), provando que quem

mata é a flag, e não o acaso.

Provado em produção, com olhos e com número: 10 de 10 entradas exibem a faixa na tela; escrita

acima do teto recusada nomeando o limite; escrita dentro dele aceita; e o valor de produção

restaurado byte a byte ao retrato inicial.

O que continua estimado, e está declarado no doc de deploy: o fator de multiplicação do pico de

memória por requisição veio de leitura de código, não de medição sob carga. Por isso a conta de

quantas requisições simultâneas cabem no teto (cerca de duas e meia) está escrita lá, junto do

aviso de que quem segura isso hoje é o corte da camada da frente. Ver {F8-54}.

Três cartões nasceram desta obra: {F8-54} (o limite anunciado que a frente corta),

{F8-55} (a mesma guarda fail-open em outras duas rotas do Hub) e {F8-56} (o placar que reprova

por acaso). Mais o {F8-57} acima, visto na tela.

Cartão novo, achado no review da Fatia A da {F4-07} em 2026-08-05, e medido, não suposto. O

limite de tamanho de envio passou a ser configurável pelo admin da agência, e **o catálogo não tem

faixa máxima**. O serviço de parse está protegido por um teto de infraestrutura próprio, mas o

processo da API do Hub lê o corpo inteiro da requisição em memória, e o container roda **sem

limite de memória** (medido: limite zero). Ou seja, um número grande digitado por um admin de uma

agência pode derrubar o processo que atende todas as agências. O risco nasceu junto com a

configurabilidade: antes, o valor fixo era o teto.

RNF-PERF-002, RNF-DISP-001, e o próprio {ART-CFG-01}.

O que implementar: faixa máxima no catálogo de parâmetros, recusada na escrita (fail-closed, é

onde a guarda mora) e não só na leitura; limite de memória no container da API, coerente com a

faixa; e leitura do corpo que não dependa de buferizar tudo antes de decidir, ou pelo menos a

recusa acontecendo antes de o corpo inteiro entrar na memória.

Como verificar (teste primeiro): tentar gravar um valor acima da faixa é recusado com o limite

nomeado; enviar um corpo grande é recusado sem que o processo cresça em memória proporcionalmente;

e o container tem limite de memória declarado.

Aceite (H1): Dado um admin de agência configurando o limite de tamanho de envio, Quando ele

informa um valor acima da faixa permitida, Então a escrita é recusada nomeando o limite, E nenhum

valor gravável permite que uma requisição de uma agência esgote a memória do processo que atende

as demais.

Cartão novo, achado durante o {F8-48} em 2026-08-12, e é o caso concreto que dá nome ao problema

que aquele cartão descreve em geral.

O que foi medido: um merge que entrou na main hoje traz no próprio assunto do commit a

afirmação "qa PASS", e o arquivo de gate de QA correspondente tem zero bytes. O gate de

review da mesma fatia tem conteúdo real, ou seja, não é falha de ambiente que atingiu os dois: **um

foi escrito e o outro não.**

O que isso significa, sem dramatizar: ninguém sabe se aquela verificação aconteceu. Pode ter

acontecido e o registro ter se perdido; pode não ter acontecido. **A ausência de registro torna as

duas hipóteses indistinguíveis**, e é exatamente isso que um gate existe para impedir.

Por que virou cartão em vez de conserto imediato, e a decisão está certa: a obra do {F8-48}

recusou-se a escrever um veredito que ninguém mediu. Seria cometer, dentro do commit que mata o

defeito, exatamente o defeito. E recusou-se a apagar o arquivo, porque apagar destrói a evidência de

que a fatia mergeou alegando gate. Registrou como pendência viva.

O que faltava, e este cartão resolve: a pendência existia só como prosa no cabeçalho de um

registro. Cobrança sem dono não é cobrança: some na próxima leitura.

O que implementar: rodar a verificação daquela fatia de verdade e gravar o gate com o que for

medido. Se ela reprovar, é achado, não fracasso: significa que algo entrou em produção sem

passar, e aí o conserto é trabalho seguinte, com número na mão.

Cuidado: aquela fatia não é do módulo de relatórios. Antes de medir, confirme o que ela mudou e

se o comportamento ainda está em produção. Reverificar código que já foi substituído é gastar

fôlego à toa.

Como verificar (teste primeiro): o gate daquela fatia deixa de estar vazio e contém veredito

medido; e a varredura do {F8-48} para de listá-lo como pendência.

Aceite (H1): Dada a fatia que mergeou alegando verificação aprovada, Quando alguém consulta o

gate dela, Então encontra um veredito que corresponde a uma medição real, E a pendência sai do

registro.

FECHADO em 2026-08-13. A verificação foi feita de verdade e o gate passou de **0 para 10.851

bytes, gravado nas duas coleções. Veredito: aprovado com ressalva**, e a ressalva é o produto.

A fatia está viva e valia medir: 23 commits entraram depois sem reverter nada, e o pacote servido

em produção é posterior ao merge. Não era arqueologia.

O achado que fecha o círculo, e é mais forte do que este cartão previa: aquele merge alegou

duas coisas no próprio assunto. A primeira, "qa PASS", tinha o gate vazio. A segunda, "review

APPROVED", tem gate com conteúdo, dizendo NEEDS CHANGES. As duas afirmações contrariadas pelo

registro que elas invocam.

E aqui está a parte que importa não confundir: o CÓDIGO está certo. A verificação exercitou o

guarda com quatro controles negativos plantados, confirmou o contrato de ponta a ponta contra a

produção real, e achou as correções que o review pedia já aplicadas na main. **O que era falso

era o registro, não a entrega.** É por isso que o defeito é insidioso: ninguém mentiu sobre o

produto. O carimbo é que ficou oco, e carimbo oco não distingue "verifiquei" de "não verifiquei".

A verificação foi refeita contra a LEI, e ficou melhor. A lição de método é essa. A primeira

medição confrontou a fatia com as próprias alegações dela (assunto do merge, comentário do

guarda, gate de review). Depois o verificador foi ler os requisitos publicados e reenquadrou o

que tinha achado. Medir a obra contra o que ela diz de si mesma é medir o eco.

O veredito da fatia ficou MAIS firme, não mais frouxo: as três cláusulas do requisito que é dela

passam, inclusive a mais difícil, que passa por construção. Uma fatia irmã ficou **parcial

declarada**: a faixa existe, mas gravação, número do caso e aparecimento na central exigem sessão

logada e não foram medidos.

Três reprovações nomeadas, todas do módulo de erros e não deste roadmap:

1. A alegação de "exaustivo por construção" do guarda não se sustenta. Uma das formas de escrever

o erro cru é acusada; três outras passam, e a que escapa é justamente a forma histórica que o

próprio gate de review daquela fatia descreve como a mais comum no código antigo.

2. Não existe verificação de cobertura, e é isso que reprova, não o número. O requisito não

exige cobrir todos os códigos de uma vez; exige que o quanto falta seja **sempre conhecido e

decrescente. Medido à mão: a interface emite 559 códigos e o catálogo tem 301**. Mas não

há série anterior contra a qual provar que diminui, porque nada mede isso. A nota do próprio

requisito é explícita: viola-se quando a verificação não sabe dizer quantos faltam.

3. 276 das 301 entradas do catálogo não têm ação sugerida (91,7%), contra um requisito que exige

mensagem humana e ação, e que manda rejeitar a gravação de entrada sem uma das duas. Não há

rejeição: o campo é opcional e nenhum guarda o cobra. É desvio entre a lei publicada e a

implementação, e pertence ao registro de erros, entregue antes desta fatia.

O que NÃO foi medido, declarado: nada de navegador logado, nenhuma prova visual renderizada. O

lado da tela foi provado por estrutura e por contrato de rede.

FECHADO em 2026-08-18. O critério do cartão era um só - *duas execuções simultâneas não podem

se ver* - e foi atendido por inteiro: um banco por execução (mhub_test_<pid>_<epoch>),

clonado de um template com schema, GRANTs e RLS de produção. **Medido: o clone leva ~840 ms e

carrega as 165 policies**, ou seja, isolar sai mais barato que a etapa de investigação que cada

frente gastava provando que a reprova não era dela.

A raiz era uma linha: scripts/test-all.sh passava o --env-file de produção ao container de

teste. O -e DATABASE_URL agora entra depois dele (o -e vence) e o banco é dropado no trap

de saída.

O template recusa a si mesmo se estiver errado: scripts/test-db-base.sh compara as policies

com produção e falha se divergirem - sem isso, um teste de isolamento multi-tenant passaria no

template e falharia no ar, que é pior que não ter template.

Contenção não cai em silêncio para produção: não conseguindo criar o banco, a suíte diz que

rodou sob contenção, que é o mínimo que o próprio cartão aceita.

A guarda permanente mede o efeito, não a configuração: lê o DATABASE_URL que o processo

recebeu de fato e reprova se apontar para produção ou fugir do padrão com marca de execução.

Duas guardas do próprio repo pegaram trabalho meu no caminho, e as duas estavam certas:

{ERR-06} mostrou que a home de {OP-01} montava faixa de erro à mão em vez de usar o

InlineErrorBanner (que deriva mensagem e contexto de relato do valor CRU do catch - guardar

a string já traduzida faz o "Avisar o suporte" chegar vazio), e {DS-01} apontou que a dropzone

de {OP-04} mudou de className e saiu do baseline nominal. Corrigidos os dois no mesmo commit.

Suíte do pacote 1631 verde; merges 3b1e920 (pacote) e 05a38fe (Hub), front deployado.

Cartão novo, medido em 2026-08-13 por três frentes independentes na mesma tarde, cada uma

chegando à mesma conclusão sem falar com as outras.

O que acontece: a suíte da API roda contra o banco vivo compartilhado. Com várias frentes

trabalhando ao mesmo tempo, ela acusa arquivos que ninguém tocou (com assinatura de **morte do

processo do banco, não de asserção) e a rodada leva três vezes** o tempo histórico. A mesma

rodada chega a marcar um arquivo como reprovado e outro como resolvido, em sentidos opostos.

O DANO É MAIOR QUE O PLACAR, e isto foi medido em 2026-08-13, não suposto: as suítes rodando de

worktrees não mergeados escrevem no banco de PRODUÇÃO. Foi assim que nasceram os 265 avisos com

endereço morto na conta real do dono, atribuídos por três frentes ao agendador de produção **até

alguém pegar uma suíte no ato**. Ou seja: a falta de banco próprio não deixa só o placar mentiroso,

ela suja o produto e ainda fabrica diagnóstico errado sobre a origem da sujeira. **Vinte e três

worktrees** ainda rodam código antigo contra esse banco.

O custo real, e é o motivo do cartão: cada frente agora gasta uma etapa inteira **provando que a

reprova não é dela**: roda isolado, compara com o checkout de produção, conta suítes concorrentes,

argumenta que o diff não tem uma linha de banco. Três fizeram isso hoje. É trabalho de investigação

que não produz nada, repetido por todo mundo, toda vez.

O dano pior é o que ainda não aconteceu: quando reprovar é normal, a reprova verdadeira passa.

Já existe o hábito de olhar um vermelho e presumir ambiente, e o hábito está certo hoje, o que é

exatamente o que o torna perigoso. Um gate que reprova por acaso ensina a ignorar gate.

O que implementar: a suíte precisa de banco próprio por execução, não do compartilhado. Como

isso se faz aqui é decisão de quem implementar, mas o critério é um só: **duas execuções simultâneas

não podem se ver. Se isolamento completo não couber, o mínimo aceitável é a suíte falhar

dizendo** que o ambiente estava sob contenção, em vez de acusar um arquivo inocente.

PARTE DISTO JÁ FOI CONSERTADO em 2026-08-13, e o conserto vale como precedente. Dois dos arquivos

que reprovavam não eram contenção: eram consequência real de um merge do mesmo dia. Um deles

porque um comentário contendo chave truncou o padrão de uma varredura, que parou de olhar e seguiu

verde, e ainda passou a afirmar que uma peça tinha consumidor quando tinha zero. Consertado na

raiz, com guarda que exige que os dois lados da conta saiam da mesma fonte, mais a guarda

equivalente do outro lado, e o agregador deixou de anunciar estouro de tempo como "resolvido".

Mergeado e verde em produção. A lição que fica: três frentes independentes chamaram isso de

"contenção do banco" antes de alguém medir o mecanismo. "É ambiente" fecha a investigação cedo.

E o próprio instrumento já dá conselho errado, medido em 2026-08-13: o agregador anunciou

"resolvido, considere remover do baseline" para um arquivo que naquela mesma rodada **estourou o

tempo. Quem seguir o conselho apaga do baseline uma falha conhecida**, e a próxima rodada passa

a acusá-la como se fosse nova, ou pior, deixa de acusá-la. É guarda falhando aberta dentro da

ferramenta que existe para nos dizer a verdade sobre o placar. Conserte isso junto: estouro de

tempo não é aprovação, e o agregador não pode tratar "não reprovou" como "passou".

Não trate como flake a ser tolerado. Marcar como instável e seguir é a resposta que transforma o

problema em permanente. O baseline conhecido já cresceu assim.

E há um custo de segunda ordem, medido no mesmo dia: ao alegar que uma reprova é do ambiente, as

frentes começaram a montar prova por comparação de tempo ("esta rodada levou o triplo do

histórico"). Uma revisão foi conferir e o número invertia: a rodada verde tinha levado mais

que a vermelha. A conclusão continuava certa. O que de fato fecha o caso é a **assinatura de morte

do processo do banco**, aparecendo em fatias sem relação entre si, cada uma reprovando coisa

diferente. Conclusão certa por prova errada continua sendo prova errada, e alegação de

alheiedade sem artefato não vale nada. Enquanto este cartão não fechar, quem alegar ambiente deve

citar o mecanismo e anexar o artefato, nunca comparar duração.

Como verificar (teste primeiro): duas execuções simultâneas da suíte terminam com o mesmo

placar que cada uma teria sozinha.

Aceite (H1): Dada a suíte rodando com outras execuções simultâneas, Quando ela termina, Então o

placar é igual ao da execução isolada, E nenhuma reprova é causada por trabalho de outra frente.

FECHADO em 2026-08-18 pelo Cenário 1, que é a recomendação do próprio cartão. Medido: fábrica

anunciava 100 MB, teto configurável 256 MB, e a frente corta em 64 MB - um envio de

80 MB morria antes de chegar, com o operador tendo respeitado o número da tela.

Fábrica desceu para 60 MB (4 MB de folga para o envelope multipart) e o teto para 64 MB:

adiantaria pouco alinhar o default e deixar o admin configurar um número que cai no mesmo buraco.

Por que não o Cenário 2: o corte da frente é a proteção de memória do processo que atende

todas as agências. O runbook do {F8-18} já tinha feito essa conta e previsto quem executaria

este cartão - e o efeito colateral bom ficou registrado lá: **com o teto gravável dentro do que a

frente aceita, o cenário de OOM por configuração deixa de ser alcançável.**

FRONT_MAX_BODY_BYTES declara o número da frente em vez de deixá-lo implícito - sem constante

nomeada a relação vira coincidência, alguém sobe o default e nada acusa. Mesmo par de {OP-08}.

Efeito colateral legítimo corrigido junto: o teto de corpo do parse-server é derivado do default,

e o teste dele redigitava "180MB" ao lado da derivação - o número fixo virou mentira quando o

default caiu, então ficou a propriedade (maior que o default), que é o que ele guardava.

Suíte 1635 verde; merges no pacote e no Hub, runbook atualizado.

Cartão novo, achado pela obra do {F8-18} em 2026-08-13, medindo a camada que o cartão dela nem

mencionava.

O que foi medido: o limite de envio que o produto traz de fábrica é maior do que o que o

servidor da frente aceita. Um envio legítimo de tamanho intermediário (acima do que a frente passa,

abaixo do que o produto diz aceitar) morre antes de chegar. O operador leu o número na tela,

respeitou o número, e o envio falhou mesmo assim.

Por que é defeito e não configuração: o produto anuncia um limite que ele não consegue

honrar. É a família de sempre (peça declarada e inalcançável), só que virada para o usuário: aqui

quem confia no número é quem opera.

Não conserte sozinho o que é decisão de produto: ampliar o que a frente aceita muda o que entra em

produção, e isso não é chamada de quem implementa. Cenário 1: baixar o padrão de fábrica para

caber no que a frente aceita (barato, imediato, e o número na tela passa a ser verdade); o preço é

que o teto do produto encolhe. Cenário 2: subir o que a frente aceita até o padrão de fábrica

(mantém o teto anunciado); o preço é mais memória em jogo e a faixa máxima recém-criada precisa ser

reexaminada contra ele. Recomendação: Cenário 1. O menor número já é o real hoje; alinhar o

anúncio à realidade não pede nada de ninguém, e subir o teto é decisão que se toma quando alguém

precisar, com o caso na mão.

PERIGO, e é o motivo de este cartão não ser trivial, achado no review do {F8-18} em 2026-08-13:

a camada da frente não é só um estorvo, é a proteção que está de pé hoje. O limite de memória do

processo foi dimensionado contra uma requisição no teto; com várias ao mesmo tempo, cabem cerca de

duas e meia antes de o processo que atende todas as agências morrer. Quem segura isso hoje é

justamente o corte da frente. **Escolher o Cenário 2 sem refazer a conta de memória remove a

proteção**, e remove exatamente o risco que o {F8-18} existiu para fechar, com todos os gates

verdes. Se subir o corte da frente, recalcule e declare quantas requisições simultâneas cabem.

Enquanto estiver nisto, meça a cadeia inteira: onde mais o produto anuncia um limite que outra

camada corta antes? Um número só é verdade se toda a cadeia o honrar.

Como verificar (teste primeiro): um envio do exato tamanho anunciado como aceito **chega e é

processado**; se não chegar, reprova nomeando a camada que cortou.

Aceite (H1): Dado o limite de envio que o produto anuncia, Quando alguém envia um arquivo desse

tamanho, Então ele é aceito pela cadeia inteira, E nenhuma camada intermediária corta abaixo do que

a tela promete.

FECHADO em 2026-08-18. As duas rotas eram tasks.ts (anexo de tarefa) e chat.ts (anexo de

conversa), as duas com parseInt(header ?? "0") - que falha aberta duas vezes: ausente vira 0

e aprova; ilegível vira NaN e, como Number.isFinite(NaN) é falso, a condição inteira é pulada e

a guarda não roda. As duas passaram a usar o lugar único, não uma cópia corrigida.

O cuidado que o cartão pede mudou o código: a folga padrão da guarda é 1 MB e essas rotas

sempre usaram 8 KB, então a folga vai explícita - adotar o padrão as faria aceitar ~1 MB a

mais, que é afrouxar, o inverso da intenção. O teste entra com o par: o ilegível que passou a ser

recusado (411) e o envio legítimo no teto que continua passando.

DIVERGÊNCIA RECONCILIADA, e a implementação viva venceu: o aceite escrito neste cartão pedia

recusar também o cabeçalho ausente. A guarda única do {F8-18} decidiu o contrário, com o

motivo no próprio arquivo - corpo sem content-length é transfer-encoding: chunked legítimo, e

o client_max_body_size do nginx já o recusa acima do teto; recusar aqui quebraria cliente

válido. Este cartão foi escrito antes dessa decisão existir. **O aceite vigente é: ausente segue,

ilegível e excedente são recusados.**

Cartão novo, achado em 2026-08-13 pela obra do {F8-53}, que foi contar os avisos do próprio módulo

e mediu o Hub inteiro de passagem.

O número, e ele é grande demais para ser aceito sem reconferência: de 7256 avisos publicados no

Hub, 6903 carregam endereço que não casa com nenhuma rota declarada no front. O módulo de

relatórios responde por uma fração pequena disso; a maior parte vem de outro módulo.

ANTES DE QUALQUER CONSERTO, MEÇA O NÚMERO DE NOVO, e por conta própria. Ele veio de uma

comparação contra a tabela de rotas que a fatia do {F8-53} montou para o seu escopo. É

inteiramente possível que outros módulos usem convenção de endereço diferente e que boa parte dos

6903 esteja certa pelo padrão deles. **Um número que diz "95% do produto está quebrado" quase sempre

quer dizer que a régua está errada**, e agir sobre ele sem reconferir seria o erro mais caro

disponível aqui.

Se o número se confirmar, ainda assim não é um cartão de conserto em massa: é um cartão de

guarda. A única conferência que existe hoje sobre esses endereços checa se o texto começa com

barra. O {F8-53} construiu, para o módulo de relatórios, um funil que confere o endereço contra as

rotas no momento da criação, fail-closed, com motivo escrito obrigatório quando o aviso

legitimamente não tem link. O trabalho aqui é levar esse mesmo funil para os outros produtores,

não sair corrigindo endereço a endereço.

Cuidado com o que já está no banco: apagar aviso publicado é destrutivo e é decisão do dono, não

de quem implementa. Meça, relate, não apague.

ENTREGUE em 2026-09-21 pelo Cenario 2, merge 087e847 no ModularHub (o codigo e todo de la;

aqui entra so a documentacao). Gates plan APPROVED, qa PASS e review APPROVED, os tres viajando

dentro do merge. Prod: /api/health 200, verificador do {P0-A2} 14/14, 0 avisos no formato

velho.

Numeros: nenhum dos que o cartao trazia fechava. A recontagem deu 8 construtores (7 no

escopo), 8 leituras de dedup, 10 predicados LIKE (8 no escopo) e 7 prefixos isentos,

contra os "6 construtores e 7 consultas" de um paragrafo e as "15 chamadas" de outro. E a

divida era 15.747, nao 8,2 mil: os 540 de /admin/% que o cartao dava como rota real eram

537 quebrados (/admin/companies nao existe) e so 3 funcionavam.

Escopo ampliado por decisao, e esta escrito no merge: absorveu o {F8-58}/{F8-59}, matando o

LIKE velho de control-jobs.ts:892. Motivo: mesmo defeito, mesma correcao, mesmo arquivo.

O achado que governou a implementacao inteira: a janela dupla do {F8-58} nunca funcionou

(o formato novo tinha 0 linhas no banco e o velho seguiu sendo gravado ate 13/09, 26 dias

depois do commit). Por isso a expiracao desta virou teste que FALHA na data, nunca cartao

datado, e o qa verificou injetando o bug "esqueceu de remover": o teste fica vermelho de

verdade.

Defeito de execucao que fica registrado: a entrega foi **deployada antes dos gates e do

merge**, o que inverte a ordem que protege (o gate deixa de poder dizer "nao entra" e so pode

dizer "reverta"). E, nos ~10 minutos entre o backfill e o deploy, o codigo ainda velho

gravou 44 avisos no formato morto, justamente quando a isencao daquele prefixo ja tinha sido

removida. Foram corrigidos pelo mesmo UPDATE idempotente; eram 4 eventos x 11 destinatarios,

todos da "Agencia Teste", entao nenhum cliente esteve exposto.

Pendencias nomeadas, que NAO reprovam o H1: o cron real nao foi disparado depois do deploy

(o executor publicou direto, para nao atingir cliente real da ADS4PROS); e a prova por clique

saiu numa empresa com o modulo Controle desligado, entao o aviso chega a parede de entitlement,

que satisfaz o H1 literal ("tela real, nunca o painel em silencio") mas nao mostrou a Central

renderizada.

O que PERDEU: a maior familia, wf_inactive (6.736 avisos, 44% do modulo), passa a cair

numa tela valida que nao lista esse tipo, porque a Central monta 3 tipos. Virou o {F8-63}.

ENTREGUE em 2026-09-21, merge 9a6ea3c no ModularHub. Gates plan APPROVED, qa PASS e

review APPROVED, os tres viajando no merge. **Provado por CLIQUE real, que e o unico jeito de

fechar este cartao:** o aviso "Workforce sem atividade registrada: Deact WF" leva a Central com

a linha destacada e o nome legivel, e o controle negativo provou o metodo (bloqueando a

pessoa pela propria interface, o item saiu do destaque e do contador; depois restaurado).

7 prints em tmp/qa-screenshots/f8-63-clique-2026-09-21/.

A alternativa obvia foi DERRUBADA por medicao, e vale registrar porque era a minha aposta:

mandar o link direto para a ficha da pessoa (/pessoas/<id>) parecia mais simples e barato.

Mas nao consertaria os 6.391 avisos ja entregues, que estao gravados com o formato antigo, e

reprovaria em 387 deles, porque 6 de 18 wf_ids medidos nao resolvem mais e a ficha

devolve 404, que e literalmente a clausula de reprovacao deste cartao. A saida escolhida conserta

os 6.391 sem tocar um byte de dado, porque o discriminador do link ja e byte a byte o

alert_key que a Central casa desde o {F8-62}.

control-notif-links.ts ficou intocado de proposito: mexer nele criaria um terceiro formato

dentro da janela dupla vigente e o primeiro ciclo pos-deploy reenviaria ate 221 avisos duplicados.

A ordem foi respeitada desta vez: migration antes da imagem (senao o primeiro "descartar"

tomaria 500 de constraint), e gates antes do merge e do deploy, que e o que o {F8-62} inverteu.

O que PERDEU: a Central deixou de ser curta e passa a expor nome de colaborador marcado como

parado numa tela que o TM abre na frente de terceiros (mitigado por filtro e dispensa no proprio

cartao); e by_type/total mudaram de escala, entao leitura historica de "total de alertas"

nao e comparavel atraves deste merge.

**ENTREGUE em 2026-09-21, merge 4e469a4, deployado pelo caminho unico (14/14) e com o codigo

novo confirmado dentro da imagem que roda.** Gates plan APPROVED, qa PASS e review APPROVED,

os tres viajando no merge.

Nao era defeito de texto, e essa foi a descoberta que mudou o tamanho do cartao: o mesmo

zero alimentava QUATRO leituras, e tres nao sao texto. A severidade (sevByThreshold), a regra

configuravel do admin (_mag >= rule.gte), a ORDENACAO (b._mag - a._mag) e o rotulo.

Consertar so a exibicao deixaria essas pessoas no fim da fila e fora de qualquer limiar, com o

texto certo. Por isso a perna que o cartao exigia era a certa.

Nao exigiu migration, ao contrario do que o cartao supunha: control-alerts.ts ja tipava

dias_inativo como number | null. A representacao propria ja existia no dado e chegava

intacta ate a leitura; era ali que morria.

Provado com BASELINE, que e o padrao que este projeto deveria repetir: revertendo o arquivo

para o commit-pai numa instancia efemera, o defeito reproduz (NULL vira "0 dias",

severidade baixa, posicoes 12 a 16 de 17); com o conserto, as 5 pessoas sobem para as posicoes

0 a 4 com "nenhuma atividade registrada". Controle negativo: uma fixture com 4 dias reais

de atividade permanece na base, severidade baixa, o que prova que o conserto nao atropelou a

lista inteira para o topo.

O que PERDEU: a lista muda de ordem para quem ja se acostumou com ela, e uma regra de admin

criada esperando "so casos de N dias" passa a incluir tambem os "nunca houve", que sao mais

graves porem nao tem numero. Isso e intencional e esta dito aqui para nao virar surpresa.

Achado do qa na prova por clique do {F8-63}, confirmado ao vivo. Em control.ts:787, uma

pessoa que nunca registrou atividade nenhuma aparece como "0 dias sem atividade" e

severidade Baixa. Medido na conta de teste: a pessoa "Deact WF" esta ha 111 dias sem

nenhuma tarefa e e exibida como o caso mais brando da lista.

A causa e de familia conhecida: ausencia de registro esta sendo tratada como zero, e zero

aqui significa o oposto do que o dado diz. O mesmo erro de ler sentinela como valor.

Observavel: quem nunca teve atividade aparece no topo da severidade, nao na base, e o texto

diz o que realmente se sabe ("nenhuma atividade registrada"), nunca "0 dias". Reprova continuar

ordenando essas pessoas como se fossem as mais saudaveis da lista.

A perna que impede a reincidencia, e sem ela o conserto do calculo nao basta: o estado

"NUNCA houve atividade" precisa de representacao propria no dado, distinta de "houve ha

pouco". Enquanto os dois compartilharem o mesmo zero, qualquer leitura futura (ordenacao,

filtro, relatorio, media) vai confundir os dois de novo, cada uma do seu jeito, e o conserto

desta tela nao protege as proximas. **O painel nao esta so deixando de avisar: ele esta

afirmando ativamente o contrario do que acontece**, que e pior que o silencio do {F8-65}.

Reprova fechar corrigindo so a exibicao da Central.

Nasceu do {F8-62}, e e o preco declarado dele. Com o link consertado, o aviso de

wf_inactive chega a /alertas, que e tela real, mas a Central monta apenas 3 tipos e esse nao

e um deles. O usuario sai do painel-em-silencio e cai numa tela que nao fala do item que ele

clicou, o que e melhor, e ainda assim nao e o que o aviso promete.

Observavel: clicar num aviso de wf_inactive leva a uma tela que mostra AQUELE item.

Reprova se a tela abrir sem o item, ou se a solucao for esconder o aviso em vez de exibi-lo.

ENTREGUE em 2026-09-22, merge 9e41c25 no ModularHub (aqui entra so documentacao). Gates

plan APPROVED, qa PASS e review APPROVED, os tres viajando no merge.

O observavel fechou: universo de leituras de dedup sobre link foi de 9 para 0 (8 em

control-jobs.ts, 1 em error-report-notice.ts).

A janela dupla do {F8-62} MORREU aqui, nao empilhou. Sairam JANELA_DUPLA_ATE, OLD_PREFIX,

prefixosDeDedup, linksExatosDeDedup, discriminadorDeLink e o bloco datado do teste; entrou

guarda estatica sem data. O motivo e simples: quando a dedup nao le o link, o formato do link

sai da pergunta. Restam so tres comentarios citando o nome, registrando que morreu.

A ordem INVERTEU em relacao ao {F8-62}, e de proposito: la a escrita mudava de formato e por

isso havia um vao; aqui a escrita e aditiva, entao foi DDL, depois escritor em dual-write,

depois backfill, depois leitor. Com o escritor ja no ar, nenhuma linha nova nasce sem chave e o

conjunto a corrigir fecha em vez de crescer. O vao deixou de existir, nao foi mitigado.

Executado em producao nesta ordem, com medicao entre cada passo: DDL aplicada com o codigo

VELHO seguindo saudavel (prova de que e aditiva mesmo); escritor deployado 14/14; backfill com

16.372 linhas ganhando chave e pos-condicao validada dentro da propria transacao (0 linhas

de control/errors sem chave); leitor deployado 14/14, producao 200.

A pos-condicao usa contagem RELATIVA, nao total absoluto, e isso importa: a tabela cresceu

44 linhas entre duas medicoes do mesmo dia, e uma assercao com numero fixo abortaria uma

migration correta.

Achado alem do inventario do plano: 4 pontos de chamada (/admin/jobs x2 e alert-actions x2)

quebrariam em silencio dentro de catch mudo por falta da chave. Corrigidos.

Provado com controle negativo, que e o que separa "nao duplicou" de "esta desacoplado": em

banco restaurado de producao (17.798 linhas), com dedupe_key o link mutado nao duplica (1

aviso) e, lendo link, duplica (2). Rollback exercitado nos dois sentidos com totais identicos.

Divida NOMEADA, que fica aberta: o commit do leitor, se for ao ar ANTES do backfill, duplica

avisos ate o backfill terminar, e nao ha guarda em codigo, so a ordem do deploy. Nesta

entrega a ordem foi garantida por execucao medida passo a passo, mas "disciplina de deploy" e

exatamente o que o {P0-A2} desmontou: documento que descreve o certo nao impede a mao que faz

diferente. O {P0-A7} e o cartao que trata essa familia.

O que PERDEU: quem depurava lendo identidade no link perde o atalho; o digest passa a

contar dedupe_key distinto (mesmo numero hoje, numero diferente no dia em que dois enderecos

forem o mesmo evento, e isso aparece em texto que o TM le); os 9 modulos que nao dedupam ganham

coluna nula em todo select *; e produtor novo de control/errors perde a liberdade de

publicar sem chave, atrito deliberado.

E o Cenario 1 do {F8-62}, que o dono mandou NAO sumir da fila, porque e ele que impede o

defeito de renascer no proximo aviso que alguem escrever.

O que implementar: coluna propria de chave de dedup em messages.notifications (schema do

ModularHub), com backfill dos avisos existentes ANTES de trocar as consultas, e o link passa a

ser so endereco de navegacao.

Por que continua valendo mesmo com o {F8-62} entregue: o Cenario 2 consertou os enderecos,

mas o campo continua com duas responsabilidades. A proxima mudanca de rota reabre exatamente

este defeito, e a janela dupla que o {F8-62} abriu e divida com prazo.

Observavel: a dedup do control nao le mais o campo link, e mudar o formato de um link

deixa de poder quebrar a deduplicacao. Reprova fechar deixando qualquer LIKE de dedup sobre

link.

Nasceu da medição do {F8-58}. No módulo control o campo link tem duas responsabilidades: é a

chave de deduplicação (control-jobs.ts:120 diz isso por escrito, "Link canônico de dedup") e é o

destino do clique (NotificationBell.tsx:114 faz navigate(n.link)). A segunda responsabilidade nunca

foi honrada: os cerca de 8,2 mil avisos do control levam ao painel inicial em silêncio (rota

desconhecida cai em path="*" e vira <Navigate to="/">). São 6 construtores e 7 consultas LIKE

vivas sobre esse campo.

O que implementar: uma das duas saídas medidas, decisão do dono, não de quem implementa. (a) coluna

própria de chave de dedup, DDL em messages (fora do schema reports), o link passa a ser só

endereço de navegação. (b) migrar o FORMATO do link para um endereço que existe (/alertas?...,

/alertas é rota real), mantendo a dedup pela mesma técnica de LIKE com a string nova, com **janela

dupla de 7 dias** cobrindo os dois formatos (o digest lê /controle/alertas/% numa janela de 7 dias;

sem a janela dupla os avisos antigos deixam de casar e republicam).

Consulta que mede a dívida a qualquer momento, sem DDL: `select count(*) from

messages.notifications where origin_module = 'control' and link like '/controle/%'`.

Como verificar (teste primeiro): um clique num aviso do control criado ANTES da mudança continua

levando a uma tela válida, nunca ao painel inicial em silêncio; um aviso criado DEPOIS da mudança tem

link que casa com rota declarada; as 15 chamadas LIKE de dedup do control continuam recusando

republicação do mesmo evento.

Aceite (H1): Dado um aviso publicado pelo control, Quando o destinatário clica nele, Então ele

chega a uma tela real do Hub, nunca ao painel inicial em silêncio, E a deduplicação do control

continua recusando republicação do mesmo evento, E a transição cobre os avisos antigos e os novos pela

janela dupla.

FECHADO em 2026-08-13, mergeado na ordem vinculante (pacote 57b6a4b, depois Hub 88c03a9) e

deployado. Eram quatro avisos, não três, e três apontavam para endereços inexistentes.

Provado por CLIQUE, que é a prova que faltava desde o começo: os três levam agora às telas certas

(agendas, portal do cliente, compositor), e o controle negativo mostra os endereços antigos

redirecionando ao painel em silêncio, sem erro. É por isso que o defeito viveu semanas com gates

verdes: todo mundo verificou que o aviso era criado, entregue, contado e lido, e ninguém clicou.

A causa raiz do erro original: um dos endereços existe, como rota de API. Foi colado como se

fosse endereço de tela.

Divergência do cartão feita de propósito, e correta: o cartão mandava apontar tudo para o

compositor. O aviso de comentário resolvido vai para o cliente, e o compositor é tela de operador:

seria trocar destino inexistente por destino proibido. Foi medido até o destinatário antes de

decidir.

CORREÇÃO DA MINHA PREMISSA, medida no deploy: eu escrevi que o aviso morto estava sendo publicado

pelo agendador de produção. Falso. Os avisos mortos são 100% da empresa de teste, e o produtor

são as suítes rodando a partir de worktrees não mergeados contra o banco de produção - uma foi

pega no ato. Produção nunca mais autora endereço morto, mas **a contagem só para quando cada frente

tomar a linha principal**. Ver {F8-56}.

O que a fatia deixa além dos três consertos: guarda que confere todo aviso do módulo contra a

tabela de rotas no momento da criação, fail-closed, com isenção por publicação (não por

arquivo), prova conferida por posição e teto de contagem. Custou quatro rodadas, e cada uma caiu

pelo mesmo motivo: marcação declarativa mais larga que a justificativa.

As cinco proteções foram provadas por QUEBRA, não por leitura: o revisor fechou cada buraco e

exigiu que o caso reprovasse. É o teste que, na fatia irmã do mesmo dia, revelou que dois casos

equivalentes eram decoração.

Cegueiras que restam estão declaradas e presas em casos, cada uma com a severidade medida: as duas

formas de apelido furam a varredura mas não a conferência em execução.

Nasceu daqui: {F8-58}, a mesma classe no Hub inteiro, com a trava de reconferir o número antes

de agir.

FECHADO em 2026-08-13, mergeado (085ba86) e no ar, com o bundle publicado e prova na tela.

As 15 divergências vivas fechadas. Placar do módulo: de 36 divergências e 15 vivas para **18 e

ZERO vivas, com o universo varrido idêntico** - foi essa igualdade que provou que a queda é

conserto e não amputação.

A causa não era cada tela: era não existir a quem perguntar. A tabela do contrato do servidor

vivia dentro dos testes, então cada tela escolhia sozinha qual permissão consultar. Ela virou

código de produção e a pergunta virou uma só, com as mesmas entradas do guarda.

Provado na tela, ator a ator: o papel de execução de fábrica, sem revogação nenhuma, deixou de

ver os controles que o servidor recusaria e continua usando o que pode - inclusive abrindo o

assistente. Publicar permaneceu, corretamente, porque aquele papel tem a permissão. **Zero recusa ao

abrir qualquer tela.**

O smoke achou o que nenhum teste pegava, e virou regra: uma tela buscava dado incondicionalmente

numa rota que exige permissão, e a pessoa levava erro só de abrir. A suíte mede o controle;

aquilo era carga. Virou invariante: toda chamada disparada na abertura é guardada pelo que exige

ou dispensada com motivo, e o invariante obrigou 13 chamadas em 7 telas a perguntar.

Cinco instâncias dessa classe apareceram, cada uma por um meio diferente - navegador, leitura,

invariante, mutação e execução instrumentada. Nenhum meio sozinho teria bastado, e o censo final

por análise sintática bateu chave a chave, provando que não há sexta.

O defeito de método que custou as rodadas: marcação declarativa que remove algo da vista da

guarda, sete vezes com nome novo. O desfecho foi eliminar o campo, não torná-lo honesto - e a

prova é adversarial: reintroduzir a declaração com outro nome não engana o invariante, porque o

que reprova é a consequência.

Fica declarado: 18 divergências latentes, o operador nunca alcança o controle porque a mesma

permissão guarda o carregamento da tela - protegidas por encanamento, não por guarda. E nove

formas que a varredura não vê, cada uma com o efeito nomeado.

Sucessor: {F8-52} prova que o servidor recusa; esta fatia prova que o produto não oferece.

Cartão novo, achado pela matriz de permissão do {F8-49} em 2026-08-13, e é o defeito do {F8-46}

letra por letra, numa tela maior, a mais usada do módulo.

O que acontece: os controles de publicar, republicar e salvar como template são

desenhados sem condição nenhuma de permissão. Quem tem acesso a compor mas não a publicar

carrega o rascunho inteiro (a rota de leitura exige só compor), vê os botões, clica e leva

recusa do servidor.

Por que é pior que o caso anterior: lá o operador perdia um clique numa tela de análise. Aqui ele

monta o relatório inteiro e descobre no fim que não pode publicá-lo. O trabalho não se perde,

mas a expectativa sim, e o produto não avisou em momento nenhum.

Uma tela irmã tem a versão fraca do mesmo: o assistente de criação é oferecido a todos, e a

recusa só aparece na hora de criar.

O que implementar: os controles só aparecem para quem tem a permissão que o servidor exige, e

reusando a mesma verificação que já virou fonte única no {F8-46}, não uma segunda condição.

Decidir explicitamente o que o operador sem permissão vê no lugar: nada, ou o controle desabilitado

com o motivo.

A matriz do {F8-49} já prende este defeito: os casos afirmam o comportamento errado **de

propósito, para que ao consertar eles reprovem** e obriguem a virar a afirmação. Não os apague:

inverta-os.

Mais duas ocorrências, achadas no review em 2026-08-13, e a segunda é pior que todas:

- "Novo cliente" é guardado pela permissão de compor, mas a rota que ele chama exige a de

criar conta. O papel de execução tem a primeira de fábrica e não tem a segunda: ele vê o

botão e leva recusa sem que ninguém tenha revogado nada. Não é caso de borda: é o padrão.

- O abridor de comentários da ficha do cliente não tem guarda nenhuma e chama rota que exige

compor, numa tela alcançável só com a permissão de identidade. Passou despercebido porque a

massa de teste devolvia lista vazia: com zero comentários o controle nem aparece, e o caso

ficou verde sem exercitar nada.

**Quinta divergência, achada em 2026-08-13 pela própria forma da matriz, sem ninguém suspeitar

dela: o painel de usuários** é liberado pela permissão de gerenciar usuários da agência, e o

servidor exige também a de gerenciar a equipe. Não saiu de inspeção humana: saiu de a

verificação passar a comparar tela contra rota. É a prova de que o conserto foi de forma, não de

caso.

Achado que vale mais que as cinco divergências: o painel de comentários parece protegido nos

dois pais que não têm guarda, e está, por dependência de dado, não por guarda. O botão só existe

quando a lista tem item, e a lista vem de rota guardada pela mesma permissão. Servindo a lista a quem

não tem a permissão, o botão aparece. Ou seja: hoje não vaza por coincidência de encanamento. **O

dia em que a origem do dado mudar, vaza sem que nada acuse**, e ninguém vai ligar a mudança da

origem a um furo de permissão. Ponha guarda de verdade nos dois pais.

Mais três, achadas pela validação em 2026-08-13, todas na ficha do cliente: importar metas exige

a permissão de compor; editar a identidade visual e encerrar o cliente exigem a de atualizar conta,

e a tela guarda as três pela permissão de identidade. Ou seja, a ficha do cliente sozinha tem

mais divergências do que o resto do módulo somado.

O que essas três provam sobre o placar, e vale mais que elas: o conjunto de divergências

conhecidas não é o total do módulo: a lista de controles verificados era montada à mão, então o

número media a lista, não o produto.

**O CONJUNTO REAL, medido em 2026-08-13 ao longo de cinco rodadas de correção do próprio instrumento,

e o número CAIU na última: 88 chamadas, 83 guardadas, 55 ações, cerca de 36 divergências: 15

vivas e 21 latentes. Não as oito que a lista curada conhecia: ela media um quinto do problema.**

Atenção ao histórico deste número, porque ele ensina mais que o valor: 5 → 32 → 34 → 39 → 36.

As quatro primeiras subidas vieram de o instrumento parar de esconder; a última descida veio

de ele parar de inventar. Ou seja, o mesmo instrumento errou nos dois sentidos, sempre por

premissa não medida. Não trate nenhum destes valores como definitivo sem o gate verde.

Guarda por PAPEL é a categoria que faltava, e foi ela que causou a sobrecontagem. Rotas exigem,

no servidor, que a pessoa seja gestora da própria agência antes de olhar a permissão. O

instrumento passou a enxergá-las (acerto), mas partindo da premissa de que **nenhuma tela consulta

papel. Cinco consultam, e em três delas tela e servidor concordam**: eram falso positivo.

A premissa era suposição, não medição, o mesmo erro que causou a subcontagem, com o sinal

trocado.

Ao consertar, lembre de duas coisas: esconder o controle por permissão não resolve divergência

por papel; e antes de tratar uma divergência por papel como real, **confira se aquela tela já consulta

papel**.

O número tem "pelo menos" na frente de propósito, e isto é parte do achado. A primeira derivação

publicou 32 e 12. A validação mediu que o instrumento **não enxergava chamada escrita em linhas

quebradas (5 invisíveis) e que três linhas da sua tabela declaravam lista vazia, e lista vazia

remove a chamada do placar por construção, escondendo duas divergências vivas**. Ou seja: as duas

formas de o número encolher em silêncio já aconteceram, as duas dentro do instrumento de medida.

Trate 34 como piso e não como conjunto até a verificação fechar com gate verde.

Divergência VIVA e LATENTE não são a mesma coisa, e esta distinção decide a ordem do trabalho.

Das 32, 12 são vivas: a pessoa clica e leva recusa. As outras 20 são latentes: o ator divergente

nunca chega ao controle, porque a mesma permissão guarda o carregamento da tela. **Latente não é

resolvida: é protegida por acidente de encanamento**, igual ao painel de comentários. Mudou a origem

do dado, vira viva, e nada acusa.

Comece pelas 12 vivas: são as que machucam alguém hoje. Mas não feche o cartão nas 12: as 20

latentes precisam ganhar guarda de verdade ou motivo escrito de por que não precisam.

Mais uma, que não estava na lista de ninguém: ativar o acesso de um contato, na ficha do cliente,

não tem guarda de permissão alguma e o servidor exige atualizar contato. Diferente de "Novo

cliente", esta exige revogação para aparecer, não nasce pronta.

A regra que o review destravou, e vale para toda guarda de permissão daqui em diante: cruzar o

controle com a permissão que a tela consulta não prova nada: ela prova que a tela é coerente

consigo mesma. A pergunta é qual permissão o SERVIDOR exige naquela rota, e o defeito vive

exatamente onde as duas divergem. Uma varredura que compara a tela com a tela é cega **por

construção** para a família inteira deste cartão.

Achado colateral, medido: existe uma permissão de criar cliente declarada nos papéis e com **zero

referências** no servidor: a tela usa outra no lugar dela. Peça declarada e nunca acionada, a

família de sempre.

Como verificar (teste primeiro): um ator com compor e sem publicar não vê os controles de

publicar e de salvar como template; um com a permissão vê e usa.

Aceite (H1): Dado um operador sem a permissão de publicar, Quando ele abre um relatório no

compositor, Então os controles de publicar e de salvar como template não lhe são oferecidos, E ele

não descobre a recusa depois de montar o documento.

FECHADO em 2026-08-18, começando pela pergunta que o cartão manda - *quais decisões ainda vêm

de campo escrito e quantas removem algo da conta* - em vez de recomeçar pelo último buraco.

Medido: 84 entradas, 28 saem da conta por tipo, e ehDivergente começa literalmente com

if (cls.tipo !== "acao") return false.

A regra que entrou é ASSIMÉTRICA, e a assimetria é o ponto: declarar "leitura" para um verbo

de escrita é proibido - é a única direção que esconde; declarar "acao" para um GET continua

permitido, com motivo escrito e entrada nomeada, porque essa direção infla o placar em vez de

encolher, e um instrumento que proíbe ser conservador empurra para o lado errado.

A fonte do verbo é o AST do cliente de API, não texto. Duas réguas por expressão regular

falharam antes, e ficam registradas porque o erro é instrutivo: casar por nome final deu **34

ambíguos** (list/get existem em dezenas de namespaces) e navegar texto contando chaves deu

62 indeterminados. Régua ruim produz número errado - o defeito que este cartão existe para

tirar daqui. Pelo AST: 84 de 84 resolvidos, zero erro, e o declarado bate em 82; as 2

exceções são a mesma entrada conservadora (comments.list).

H1 executado: falsifiquei api.companies.patch (PATCH) para "leitura" e a guarda reprovou

nomeando entrada e verbo. Restaurado.

Dívida minha que a fatia revelou, e quem pegou foi a guarda do {F8-49}: o

api.reports.agencyReports, criado por mim em {OP-01}, entrou no módulo **sem contrato de

permissão declarado e sem a home perguntar por ele** - ela ainda usava a forma anterior ao

{F8-51}. Agora a home pergunta pelo método, não dispara chamada que o servidor recusaria, e o

método tem sua linha no contrato com a mesma capability do handler. Os três placares literais

subiram com motivo no diff (96→98 varridas, 82/83→83/84 guardadas) e o CompanyScopeSwitcher

entrou na fronteira declarada, porque {OP-01} o trouxe para o chrome. Vivas continuam 0.

201 testes do módulo verdes, typecheck limpo, front deployado e conferido na tela.

Cartão novo, nascido em 2026-08-13 de sete rodadas de gates sobre o {F8-49}, e ele existe porque a

busca por consertos pontuais foi encerrada de propósito.

O que aconteceu, e o histórico é o achado: a verificação de permissão precisa marcar coisas para

decidir o que conta como divergência. Cada marcação que remove algo da conta virou um jeito de

apagar defeito real com a suíte verde. A sequência medida foi **lista vazia, depois "sem guarda",

depois "papel da tela", depois o recorte de ação e leitura, e cada nome nasceu dentro do conserto

do anterior. Seis vezes. Ao fim, era possível apagar 12 das 15 divergências vivas** trocando uma

palavra num campo.

O que NÃO está errado, e é importante não confundir: o número em si. As 36 divergências e as 15

vivas foram recomputadas por três medições independentes, com os invariantes fechando, e não

dependem dessas guardas. O que se pode falsificar é a **proteção contra alguém adulterar os campos

depois**.

Por que parou de valer a pena consertar caso a caso: fechar um caminho criava o seguinte. O

problema deixou de ser o campo e passou a ser o desenho: um instrumento que decide a partir de

campo escrito à mão sempre poderá ser convencido por quem escreve o campo.

O que a fatia entregou no lugar, e foi a decisão certa: os três caminhos conhecidos ficaram

presos por casos que afirmam a existência do buraco. Fechar qualquer um deles quebra o caso e

obriga a reescrever a declaração. Ninguém é enganado, porque os furos estão nomeados e presos por

máquina.

O que implementar aqui: tirar a decisão do campo escrito. O caminho provável é derivar a

classificação da mesma forma que a lista de chamadas já é derivada (do próprio código), de modo que

marcar não seja uma opção. Enquanto isso não existir, o número vale enquanto alguém revisar os campos, e

isso está declarado no topo do arquivo.

Cuidado ao começar: não recomece pelo último buraco. **Comece perguntando quais decisões daquele

instrumento ainda vêm de campo escrito** e quantas delas removem algo da conta. Foi essa pergunta,

feita tarde, que revelou o padrão.

Como verificar (teste primeiro): falsificar qualquer campo de classificação não consegue

reduzir a contagem de divergências vivas sem que algum caso reprove.

Aceite (H1): Dada a verificação de permissão, Quando alguém altera uma marcação de classificação

para esconder uma divergência, Então algum caso reprova, E a contagem de vivas não pode ser reduzida

por edição de campo.

FECHADO em 2026-08-18, 8 PASS / 0 FAIL contra o banco e as rotas reais. Cada capability do

módulo tem um caso que chama a rota de verdade (reportsRoutes.request, passando pelo roteador

do Hono) com ator que não a tem, e afirma 403.

O ator é derivado em dois níveis, nunca escrito à mão (é o que o cartão manda reusar): o papel

sai de ROLE_DEFAULTS - o primeiro cujos padrões não incluem a capability -, com afirmação de que

existe um papel que tem (sem esse par, verde poderia significar só que ninguém a tem); e o

usuário sai do banco, por consulta, sem criar nem apagar nada. O conjunto de capabilities

também é derivado, e um caso exige que toda capability tenha rota: capability nova sem cobertura

reprova nomeada.

Três coisas que a construção ensinou, e as três viraram código:

(1) 401 e 403 são respostas diferentes e o teste as separa - a primeira rodada deu 401

(AUTH_ACCESS_REVOKED, o middleware exige sub existente e ativo), e sem essa distinção eu teria

contado a recusa do gate de sessão como se fosse a de permissão.

(2) a ordem dos gates é entitlement → capability: a segunda rodada deu 404

(MODULE_NOT_ENABLED) porque o ator era de agência sem o módulo; passar do primeiro é condição

para medir o segundo.

(3) quando o teste acusou GET /settings/identity respondendo 200 para workforce, **o

defeito era do mapa do próprio teste**, não do servidor - o contrato já declara aquela leitura

como aberta ao tenant, e quem exige a capability é o PUT. Um instrumento que só sabe acusar o

servidor nunca teria revelado isso.

Papel sem ator ativo em agência com o módulo ligado faz o caso ser pulado dizendo por quê -

nunca contado como aprovado. Merge 291e7cd.

Cartão novo, do limite que o {F8-49} declarou ao entregar (2026-08-13). Aquela fatia provou a

metade da tela: quem não tem a permissão não vê o controle. A metade do servidor, que ele

de fato recusa, foi estabelecida lendo o guarda, não exercitando a rota com um ator revogado.

O que foi medido e é o vazio: as suítes das rotas do módulo tocam só o caminho positivo.

Nenhuma prova que a resposta é recusa quando quem chama não tem a permissão.

Por que importa mesmo com a tela consertada: esconder o botão é conveniência, não segurança. A

rota continua exposta a quem a chame direto, e é o servidor que precisa recusar. Se algum dia a

guarda do servidor cair, nada acusa: a tela seguiria escondendo o botão e o produto pareceria

correto.

É a mesma família que este projeto já nomeou: caminho negativo nunca exercitado é

indistinguível de caminho negativo quebrado.

O que implementar: para cada rota do módulo que exige permissão, um caso que a chame com ator

sem ela e afirme a recusa. A armadilha já está resolvida no {F8-49}: o ator sem permissão se

deriva dos padrões do papel, com afirmação de que ele realmente a tinha; reuse essa forma, não

escreva ator à mão.

Como verificar (teste primeiro): remover a guarda de uma rota faz o caso reprovar; com a guarda,

passa.

Aceite (H1): Dada uma rota do módulo que exige permissão, Quando ela é chamada por ator sem essa

permissão, Então a resposta é recusa, E existe caso que reprova se a guarda for removida.

FECHADO em 2026-08-13, mergeado (1cc0e0b). Fatia só de teste: nada de produção mudou, e o valor

dela é a medição que o {F8-51} agora usa.

O placar, sobrevivente de cinco recomputações independentes: 88 chamadas varridas, 83 guardadas,

55 ações, 36 divergências, 15 vivas, 21 latentes.

Custou dez rodadas, e o histórico do número é a lição: 5, 32, 34, 39, 36. As subidas vieram de o

instrumento parar de esconder; a descida, de ele parar de inventar. Errou nos dois sentidos,

sempre pela mesma causa: premissa lida e não medida.

O defeito que reapareceu seis vezes com nome novo: toda marcação que remove algo da conta

virou um jeito de apagar defeito real com a suíte verde. Lista vazia, depois "sem guarda", depois

"papel da tela", depois o recorte de ação e leitura, e cada nome nasceu **dentro do conserto do

anterior. Em certo ponto era possível apagar 12 das 15 vivas** trocando uma palavra.

Onde a busca parou, e por quê: fechar um caminho criava o seguinte, então o problema deixou de ser

o campo e passou a ser o desenho. Os caminhos restantes ficaram **presos por casos que afirmam o

buraco: fechar qualquer um quebra** o caso e obriga a reescrever a declaração. O conserto

estrutural é o {F8-61}.

A armadilha mais fina, e ela quase passou: a primeira tentativa de prender os buracos exercitava

cópias do critério. Fechando os buracos de verdade, a suíte seguia verde, e a nota que

prometia proteção virou mentira. O teste que pegou isso: feche o buraco e exija que o caso quebre.

E o fecho não foi por código, foi por HONESTIDADE: a última reprova foram duas frases que

anunciavam cobertura inexistente, dentro de testes verdes, que é onde ninguém reabre para conferir.

O ganho concreto além do número: a delegação virou classe, derrubando o vão de 57 para **7 rotas

em 713**, e as 7 restantes são leitura pública ou interna.

Cartão novo, medido em 2026-08-12 durante a reverificação do {F8-46}. O gate de QA daquela fatia

estava com zero bytes, e o relato do próprio QA afirmava "gravado e relido do disco". A releitura

não aconteceu, ou não verificou nada.

NÚMERO CORRIGIDO, e o erro foi meu, do mesmo tipo que este projeto já pagou hoje. A primeira

redação dizia três arquivos vazios: eu contei o que apareceu no fim de uma listagem, e li a

amostra como se fosse o universo. Medido depois, sem limite: **994 gates no total, 121 com zero

bytes, e (o número que importa) 76 deles em qa/ e review/, que são exatamente os que

autorizam merge**. A obra achou 123 pelo critério mais forte (pega também arquivos de 2 e 5 bytes,

com só quebra de linha ou marca de codificação), mais 21 no checkout de produção.

Ou seja: quase quarenta por cento dos gates de QA e de review deste projeto não registram nada,

e cada um deles carimbou uma entrega.

Por que isto é pior que gate ausente: gate ausente bloqueia o merge, porque falta. Gate vazio

passa: o arquivo existe, o nome bate, e ninguém abre. Ele autoriza a entrega **sem deixar

registro de o que foi verificado**, e o histórico do projeto fica com um carimbo que não carimba

nada.

A causa é a mesma que este projeto já nomeou várias vezes: a verificação é **declaração de quem

escreve** ("reli o arquivo"), não medição. Todo pedido de gate desta sessão passou a incluir "releia

depois de escrever", e mesmo assim um saiu vazio, porque a instrução depende de disciplina, não de

construção.

O que implementar: o gate passa a ser verificado por construção: arquivo com zero bytes, ou sem

veredito legível, não conta como gate. Onde essa verificação vive é decisão da fatia: no fluxo

que consome os gates antes de mergear, ou numa varredura que roda no comando único da raiz e acusa

qualquer gate vazio no diretório.

Prefira a segunda ou as duas: a primeira protege daqui para frente; a segunda **acha os que já

estão lá**, que é como este defeito foi descoberto das duas vezes.

Junto, e é trabalho de arqueologia curto: os três arquivos vazios de hoje e de maio precisam ser

reconstituídos ou removidos com registro do motivo. Gate vazio no histórico é pior que ausência,

porque parece prova.

Como verificar (teste primeiro): um gate com zero bytes é acusado; um gate com veredito passa; e

a varredura encontra os que já existem no diretório hoje.

Aceite (H1): Dado um arquivo de gate vazio ou sem veredito, Quando a verificação roda, Então ele

é acusado e não conta como aprovação, E os gates vazios já existentes no repositório são listados.

FECHADO em 2026-08-13, mergeado (fd26508). QA PASS e review APPROVED, ambos em duas rodadas.

A verificação roda no comando único, aborta antes do resto, e o critério é mais forte que "zero

bytes": pega arquivo só com espaço, só com quebra de linha, só com marca de codificação, e texto

sem veredito legível. Zero falso positivo medido em 922 gates legítimos, por três partes.

O furo que o QA achou, e é o cartão em miniatura: um gate dizendo **"em andamento, ainda não

verifiquei nada" passava, porque o rótulo de estado valia como veredito. A guarda que exige

veredito aceitava a declaração explícita de que nada foi verificado.** Corrigido de forma estreita

(os rótulos deixaram de valer sozinhos, nenhuma palavra de desfecho foi tocada), com custo medido em

zero antes do commit.

O Major do review, e o diagnóstico honesto: a varredura não alcançava o workspace, que é

justamente onde os gates deste loop são escritos. A obra mediu primeiro e achou que o workspace

não existe na produção: sem montagem, sem cópia. Ou seja, "descobrir melhor" era impossível.

A solução foi declarar o endereço por máquina e anunciar a cobertura.

E aí veio o menor mais irônico da fatia: o anúncio **se desligava quando alguém declarava uma

raiz**: a guarda que torna a rodada honesta se calava exatamente na configuração corrigida. Virou

tabela de contrato: uma linha por coleção, sempre, com estado varrida ou não alcançada, e um

aviso de que o verde só vale para o que foi varrido. Declarar um caminho qualquer **não compra

cobertura que não existe**.

O merge conflitou com DUAS fatias de outras sessões, que tocaram os mesmos arquivos e numeraram

o mesmo passo. O método da resolução é a lição: resolver marcador a marcador teria perdido

trabalho alheio, porque os blocos são parecidos e foram entrelaçados. Partiu-se da main inteira

e inseriu-se o bloco novo: assim nenhuma linha alheia pode sair, por construção. Medido depois:

54 adições, zero remoções. Hoje três guardas convivem no comando único.

FECHADO em 2026-08-13, mergeado (56570e2) e em produção. Decisão tomada sem devolver a escolha

ao dono: o cartão já recomendava avisar dentro do produto, sem canal externo, e foi isso,

reusando o mesmo canal que já avisava o autor na resolução. Zero tabela, zero serviço, zero e-mail.

O defeito que a obra quase cometeu, e é o motivo de terem sido duas rodadas: o critério de quem

recebe reusava a função de permissões que as rotas usam, mas reimplementava as entradas dela:

filtrava os grants por agência (quando a revogação é arquivada por usuário) e lia o papel da coluna

do perfil (quando o guarda lê o papel do vínculo, com o modo multi-agência ligado em produção).

Resultado medido: o aviso incluía quem o servidor recusa, alcançável por 9 usuários com vínculo

fora da própria agência. Era exatamente o defeito do {F8-46}, cometido dentro do conserto dele.

E o controle negativo não podia ter pegado: arquivava a revogação sob a agência **do próprio

relatório, que é justamente o caso que o filtro defeituoso enxerga. Ele nunca poderia falhar.**

A rodada 2 refez o par num ramo que não tinha um único caso, e incluiu o gêmeo sem a revogação:

sem ele, o caso mediria o vínculo em vez da revogação. A validação removeu o gêmeo para conferir: a

asserção fica verde pelo motivo errado. Peça que sustenta peso.

Provado na tela, não só no banco: comentário real de um contato real gerou 5 avisos, um por

operador e nenhum para o autor; o sino subiu, o aviso abriu, o link levou ao compositor com o

comentário à vista, e o contador caiu só para quem leu: os outros quatro seguiram não lidos.

Todo o dado de teste apagado nominalmente, com conferência de órfãos depois.

O que fica declarado como decisão, não como achado: super administrador sem vínculo com a

agência não recebe, para não receber comentário de todos os inquilinos. E o tipo de aviso é

obrigatório: o operador não consegue silenciar comentários.

Dois cartões nasceram daqui: {F8-53} (avisos apontando para rota inexistente) e a confirmação

medida de que o vermelho da suíte tinha causa real, não só contenção: ver {F8-56}.

Cartão novo, confirmado em 2026-08-11 pelas duas partes que validaram o {F8-17}, de forma

independente: as rotas que listam e que marcam como resolvido um comentário de cliente **não

têm chamador nenhum**: nem na tela do operador, nem em serviço nenhum.

O que isso significa no produto, e não é detalhe técnico: o cliente abre o relatório, escreve um

comentário, e ele chega ao banco. O operador vê apenas um contador agregado na tela de

análise. Não há onde ler o que foi dito, nem como responder ou dar por resolvido.

É a pior forma da família "peça pronta e inalcançável", porque desta vez quem fica pendurado é o

cliente final: ele escreve achando que alguém vai ler, e do outro lado não existe leitura

possível. O sistema promete uma conversa que não pode acontecer.

A metade que existe é a mais difícil: receber, guardar, controlar acesso e contar já está pronto

e em produção. Falta a tela.

Ao construir, decidir explicitamente: o operador é avisado de comentário novo, ou precisa

entrar para descobrir? Contador que ninguém olha é o mesmo problema com outra roupa.

Como verificar (teste primeiro): um comentário deixado por um cliente aparece para o operador com

o texto, o autor e a data; ele consegue marcar como resolvido; e o que foi resolvido deixa de pesar

como pendência.

Aceite (H1): Dado um comentário deixado por um cliente no relatório publicado, Quando o operador

abre o produto, Então ele lê o comentário e sabe quem escreveu e quando, E consegue marcá-lo como

resolvido, E não depende de contador agregado para descobrir que existe.

FECHADO em 2026-08-12, mergeado (d843dc3) e deployado. QA PASS e review APPROVED, este na

terceira rodada. Um componente só, reusado em três telas, consumindo as rotas que **já existiam e

estavam sem chamador**: nada novo no servidor.

O crítico que o review pegou, e é a família que esta sessão já pagou: a tela de análise exigia

permissão mais fraca que as rotas de comentário, então quem tinha acesso à análise **via o botão

e levava recusa silenciosa**. Oferecer ação que o servidor vai negar gasta o tempo da pessoa e falha

depois.

A rodada mais instrutiva foi a terceira, e ela não era sobre o código: era sobre a PROVA. O

conserto estava certo desde a segunda rodada, confirmado por construção, comparando a condição da

tela com o que o servidor exige nos dois métodos. O que não se sustentou foi a evidência. O

review mediu e desmontou: o usuário de teste era de um papel que **já tinha a permissão por

padrão**, não havia registro de revogação no dia, e a metade positiva não tinha artefato.

E o ponto mais fino veio do próprio autor, ao admitir: aquela tela **não pode ser provada por

imagem, e não por limitação de ferramenta, mas por decisão de produto**. O texto que aparece

para quem não tem a permissão é deliberadamente idêntico ao botão em cor, peso e tamanho, porque o

número não deve sumir. Duas capturas dos dois casos saem iguais.

O que substituiu a prova: uma matriz de quatro atores contra o elemento produzido, com

controle negativo nos dois sentidos: o defeito original (sempre oferece) e o inverso (nunca

oferece, nem a quem pode) reprovam três casos cada. O review recontou linha a linha e confirmou que

o sentido "guarda severa demais" está coberto, que é o que costuma escapar.

Ganho colateral: a expressão de permissão estava copiada em cinco telas. Virou fonte única,

com zero cópias residuais confirmadas por varredura, e o escopo declarado no próprio arquivo.

Dois cartões nasceram de falhas do PROCESSO de verificação, não do produto: {F8-48} (o gate de QA

saiu com zero bytes enquanto o relato afirmava tê-lo relido, e há outros dois assim, de maio,

nunca notados) e {F8-49} (o QA exercitou tudo como super administrador, **o perfil que nunca é

recusado**, e por isso não podia achar este defeito). O terceiro é {F8-47}, a metade que a fatia

deliberadamente não cobriu: o operador ainda depende de visitar a tela para descobrir que há

comentário novo.

**Cartão novo, e ele não nasce de um caso: nasce de a mesma coisa ter aparecido cinco vezes em duas

varreduras (2026-08-05). Backend pronto, testado, mergeado, com o cartão fechado, e nada no

painel o chama**. Já apareceram assim: a base sazonal do cliente (coluna e rota prontas, zero

referência na tela), o modelo de venda do cliente (idêntico, e o cartão que o entregou está [x]),

a visibilidade de métrica por cliente (três rotas prontas, zero referência na tela), o teto de

verbosidade por bloco, e os dois tetos de tempo da composição do {F8-16}. Consertar os cinco um a

um é o erro conhecido da casa: **guarda que percorre lista curada só protege o que alguém lembrou

de listar**, e a sexta ocorrência entra em silêncio com o placar verde.

RNF-MANUT-003, e o critério de aceite de todo cartão deste roadmap (artefato só fecha se existe

E é alcançável).

O que implementar: uma varredura exaustiva por construção, que enumere toda rota do módulo

e toda função exportada do pacote e confronte com quem de fato as aciona no caminho que uma pessoa

percorre, produzindo a lista das órfãs. Ela reprova quando aparece órfã nova, e o legítimo se anota

com o motivo, para a rodada seguinte mostrar só o que é novo, detector barulhento vira

catraca, não gate. Depois, ligar as órfãs achadas ou reabrir os cartões que as declararam

entregues; e cada cartão reaberto diz qual metade existia.

Como verificar (teste primeiro): acrescentar uma rota que ninguém chama e confirmar que a

varredura REPROVA; anotar uma órfã legítima com motivo e confirmar que a rodada seguinte não a

mostra mais; e conferir que as cinco já conhecidas aparecem na primeira execução.

Aceite (H1): Dado o conjunto de rotas e funções exportadas do módulo, Quando a varredura roda,

Então toda peça sem quem a acione em produção é listada, E a lista das cinco já conhecidas aparece

nominalmente, E uma peça órfã nova reprova a integração contínua, E órfã anotada com motivo não

reaparece como ruído.

FECHADO em 2026-08-12, mergeado (4428ef6). QA PASS e review APPROVED, ambos na segunda rodada.

Este cartão é o melhor argumento a favor dos gates que esta sessão produziu. A primeira entrega

afirmou 179 peças órfãs. Os dois gates reprovaram de forma independente, cada um amostrando e

verificando item a item: o review achou 5 falso-positivos em 7 rotas, o QA achou 7 em 13. E o

pior: uma rota ativa em produção, documentada no manual do projeto como servindo tráfego real,

entrou na lista com o motivo escrito "nenhum chamador real foi encontrado". A lista não era só

ruidosa: afirmava falsidade com aparência de fato apurado, e quem a seguisse teria quebrado a

página de análise.

Sete causas de extração de texto, não três. O review nomeou três, o QA achou uma quarta

(prefixo de host), e o autor achou mais três ao consertar, incluindo o fallback **emprestando o

chamador de um método para outro no mesmo caminho**.

A lição que fica, e ela estava escrita no próprio arquivo: o autor já havia caçado essa exata

classe de problema para um delimitador, com varredura por estado, e **não aplicou a mesma disciplina

ao outro**. A rede de segurança anunciada não funcionava. Análise por expressão regular sobre código

real quebra nos casos que importam. O conserto foi trocar por varredura de estado, **na raiz, sem

exceções pontuais**.

Placar final: 24 rotas órfãs viraram 9, e o QA verificou todas as nove, não uma amostra,

trazendo a main (35 commits à frente) para dentro antes de medir. A metade dos exports do pacote foi

validada como sã pelos dois gates desde a primeira rodada.

O achado de produto que a varredura revelou virou {F8-46}: o cliente comenta no relatório

publicado, o comentário chega ao banco, e o operador não tem tela para ler nem responder: só um

contador agregado.

Nota de honestidade registrada pelo QA: uma rota citada no review antigo como exemplo de

falso-positivo é, hoje, organicamente órfã: três medições independentes concordam. Fica escrito

para quem ler o histórico não repetir a alegação antiga sem reconferir.

Cartão novo, achado de lado durante a contagem da {F4-07} em 2026-08-05. O teto de tempo por

bloco e o piso e teto de tempo por documento existem como valores no pacote, **e as funções que os

aplicam não são chamadas em lugar nenhum fora do próprio módulo**. O sintoma esperado disso é que a

composição de IA roda hoje sem limite de tempo: um provedor lento não é cortado, o operador fica

esperando, e o requisito de desempenho que promete uma janela de dez a trinta segundos não tem

quem o faça valer.

RNF-PERF-002. Este cartão é risco operacional, não configuração, por isso saiu de dentro da

{F4-07} em vez de virar mais uma linha de parâmetro sem painel.

MEDIR ANTES DE CONSTRUIR: a primeira tarefa é confirmar o sintoma no caminho REAL de

composição, não no pacote isolado. Pode existir um teto em outro lugar (no cliente de IA, no

servidor de aplicação, no proxy) que ninguém lembrou de contar, e nesse caso o defeito é a peça

duplicada, não a ausência. Confirme com uma composição real que demore.

O que implementar (se o sintoma se confirmar): o caminho real de composição passa a aplicar o

teto por bloco e o teto por documento, com o comportamento de estouro sendo o mesmo fail-loud que

a cadeia de IA já usa quando falha: nada de narrativa pela metade publicada como se fosse inteira.

MEDIÇÃO FEITA EM 2026-08-10, e ela reescreve o que construir. O cartão mandava medir antes de

construir, prevendo que "pode existir um teto em outro lugar que ninguém lembrou de contar". **Havia,

e é pior do que não haver.**

1. As peças de teto não têm chamador nenhum. Nem no pacote fora do próprio arquivo, nem no

programa do leitor, nem na API. Só o barril as exporta, e **o comentário do barril afirma que a

API as usa**. Mais uma afirmação de código que descreve intenção como se fosse fato.

2. O cliente de IA não tem teto próprio. Nenhum sinal de aborto, nenhum tempo limite.

3. O proxy corta em 60 segundos. A composição é síncrona sobre uma rota servida atrás do

proxy, cuja leitura está limitada a 60 segundos, enquanto o bloco vizinho, de outro serviço, usa

900. Ou seja, o teto existe, mas na camada errada.

Por que o teto do proxy é pior que teto nenhum, e este é o achado que importa:

- Ele derruba a conexão, não o trabalho. O operador recebe um erro de gateway, e a composição

continua rodando no servidor e gravando. É exatamente o desfecho que o aceite proíbe: narrativa

pela metade tratada como inteira, agora sem ninguém olhando.

- Ele não é uma falha nomeada. O operador não vê "estourou o tempo", vê o erro genérico do

proxy, indistinguível de o serviço estar fora do ar.

- Ele torna o orçamento desenhado inalcançável. O piso por documento é de 60 segundos e a

referência é de 6 por bloco, então qualquer documento acima do piso seria cortado pelo proxy

antes de o teto do próprio produto valer. O orçamento que o pacote calcula nunca chega a decidir

nada.

Consequência para o que implementar: não basta ligar as peças ao caminho real. É preciso que o

teto da aplicação seja menor que o do proxy, ou que a composição deixe de depender de uma

conexão aberta. Ligar o orçamento sem tratar a camada de baixo entrega um teto que nunca dispara,

com o placar verde.

Como verificar (teste primeiro): uma composição forçada a demorar além do teto é interrompida

e o operador vê a falha nomeada, em vez de esperar indefinidamente; e uma composição normal não é

afetada. Além disso, e por causa da medição acima: provar que o corte veio da aplicação e não

do proxy, e que nada continuou gravando depois do corte.

FECHADO em 2026-08-10, mergeado (2cb3a94 no pacote, 4e4982a no Hub) e deployado. QA PASS e

review APPROVED. O teto passou a ser da aplicação, fixado abaixo do teto do proxy, com falha nomeada

no canal de falha que já existia, nenhum canal novo. O disparador agendado passa pelo mesmo caminho,

então não sobrou metade sem teto.

A prova mais difícil do aceite foi feita rodando, não afirmando: forçaram a chamada a demorar 53

segundos, mediram o retorno em ~50, esperaram a resposta tardia chegar de verdade e releram o

banco antes e depois: bytes idênticos. Nada gravou depois do corte, que era o desfecho proibido.

A pergunta que decidia se isto podia ir ao ar foi respondida com número. Eu tinha levantado o

risco de o teto impedir documento real de existir, com base na fórmula de orçamento (108 a 150

segundos para 18 a 25 blocos). O QA mediu o tempo real: 1,2 a 2,4 segundos, oito execuções.

A fórmula não era medição: a composição é uma chamada de IA só, e o número de blocos quase não

move o relógio. Ver {F8-37}, onde a correção está registrada junto do que sobrou de risco de verdade.

Dívida declarada, não escondida: o teto da aplicação só funciona porque é menor que o do proxy, e

esse vínculo é prosa nos dois lados, não verificação. Quem baixar o número do proxy reabre o

defeito sem que teste nenhum acuse. O review propôs tornar o valor operável sem reconstruir a

imagem; ficou para depois de propósito, porque a resposta do QA podia mudar o desenho inteiro, e

trabalho feito antes da resposta é trabalho jogado fora.

Aceite (H1): Dado uma composição que ultrapassa o teto de tempo declarado, Quando ela roda,

Então é interrompida no teto, E o operador recebe a falha explícita, E nenhuma narrativa parcial é

entregue como se estivesse completa.

Cartão novo, achado no planejamento do {F8-07} em 2026-08-08. O tipo de imagem vetorial está na

lista de tipos aceitos pelo envio de arquivo, e o leitor serve esse conteúdo embutido na página

pública. Imagem vetorial não é só imagem: ela carrega script. Um arquivo desses, enviado por quem

tem acesso ao painel, vira script armazenado executando na página que o cliente final abre, num

serviço que hoje ainda não tem criativo nenhum circulando.

RNF-SEG-001, RF-ING-001, RN-006.

Por que agora e não depois: hoje não há nenhum bloco de mídia em nenhum rascunho ou retrato de

produção, ou seja, a superfície é zero. No dia em que o {F8-07} ligar a inserção de criativos,

ela deixa de ser zero. Fechar isto antes é barato; depois, é incidente.

O que implementar: tirar o tipo vetorial da lista de aceitos, ou, se houver motivo real para

aceitá-lo, servi-lo de forma que não execute (nunca embutido) e sanitizá-lo na entrada com o mesmo

rigor do parse isolado. A primeira saída é a que o {F8-07} não precisa; escolha-a a menos que

alguém demonstre a necessidade.

Como verificar (teste primeiro): enviar um arquivo vetorial com script embutido e confirmar que

ele é recusado na entrada; e, se a decisão for aceitar, que a página pública o serve sem executar

nada.

Aceite (H1): Dado um arquivo de imagem vetorial contendo script, Quando alguém o envia, Então

ele é recusado na entrada, E nenhuma página pública serve conteúdo capaz de executar script vindo

de arquivo enviado.

MEDIÇÃO EM 2026-08-10, e ela DERRUBA a parte mais alarmante deste cartão. A redação acima afirma

que o arquivo "vira script armazenado executando na página que o cliente final abre". **Isso não é

verdade hoje**, e foi medido, não deduzido: o leitor aplica a política de segurança de conteúdo em

toda resposta, aplicada no início do tratador de requisição e portanto também na resposta do

proxy de imagem, com script-src sem unsafe-inline mais nosniff. Script dentro de arquivo

vetorial não executa na página pública, nem embutido nem aberto direto. O cartão nasceu de

leitura de código e superestimou a exposição.

O que a medição NÃO derruba, e é o que sustenta o cartão de pé:

1. A camada de armazenamento continua aceitando o tipo vetorial. Quem barra é uma rejeição

aplicada em um único ponto de chamada (a rota de bloco de mídia), com a decisão declarada no

próprio comentário como local e contida até este cartão fechar.

2. Guarda por ponto de chamada nomeado faz todo caminho novo nascer furado, em silêncio. Provado

no mesmo dia: a rota de logo do cliente ({F8-08} Fatia B) entrou como segundo caminho para o

mesmo armazenamento sem a rejeição, e ninguém decidiu isso: simplesmente não havia como

lembrar. Fechado ali por reuso da mesma constante, mas o terceiro caminho vai repetir.

3. A ponta do compositor não foi medida. A defesa que salva é do leitor; o mesmo arquivo é

desenhado também no preview do operador, que é outra origem, com outra política. Medir essa

ponta faz parte deste cartão, e é onde o risco pode estar de verdade.

Consequência para a prioridade: deixa de ser urgência de incidente e passa a ser dívida

estrutural. A saída continua sendo a mesma que o cartão já indicava (tirar o tipo da lista de

aceitos no armazenamento, e não em cada rota), porque é ela que troca inclusão nomeada por

construção.

Cartão novo, achado em 2026-08-13 pela obra do {F8-20}, que foi contar arquivos em produção para

dimensionar outro problema e esbarrou neste.

CUIDADO AO REMEDIR, e isto é parte do cartão: a contagem de linhas da tabela é agregado móvel:

a revisão mediu 0, 2, 4 e 0 no intervalo de um minuto, porque há ingestão e expurgo vivos. **Quem

remedir no minuto errado fecha este cartão por engano. A prova que vale é por identificador**: os

8 arquivos do disco não têm linha correspondente, e foi assim que a revisão confirmou.

O que foi medido, em produção: 8 arquivos de artefato no disco sem nenhuma linha correspondente

na tabela que os indexa. A rotina que expira artefatos por tempo de vida **registrou os identificadores

como expurgados** e os bytes ficaram. O registro diz que o trabalho foi feito; o disco diz que não.

É a mesma família do {F8-20}, e é por isso que ele nasceu aqui: processo que **relata sucesso sem

ter feito o trabalho**. A diferença é que lá o alcance nunca existiu, e aqui ele existiu pela metade,

o que é pior, porque a auditoria registra conclusão.

Consequência que já está de pé: qualquer varredura guiada pela tabela não acha nenhum dos 8.

A eliminação de dados do {F8-20} só os alcança porque foi construída para varrer o diretório, e

não a tabela, decisão que nasceu justamente desta medição.

O que implementar: a expiração apaga os bytes, e relata nominalmente o que apagou, para

"não havia nada" continuar distinguível de "não olhei". Os 8 já existentes precisam de destino

decidido, e apagar arquivo de produção é decisão do dono, não de quem implementa: meça, liste, e

traga.

Meça a causa antes de consertar: o expurgo falha e mesmo assim carimba, ou nunca tentou tocar o

disco? São consertos diferentes, e o segundo tem irmãos em outras rotinas.

Como verificar (teste primeiro): um artefato que passa do tempo de vida some do disco, e o

relatório da expiração o nomeia; e um artefato dentro do prazo continua intacto.

Aceite (H1): Dado um artefato que passou do tempo de vida, Quando a expiração roda, Então o

arquivo é removido do armazenamento, E o resultado declara o que foi removido, E nenhuma linha é

carimbada como expurgada sem que os bytes tenham saído.

Cartão novo, achado pela revisão do {F8-20} em 2026-08-13, ao procurar o quinto caso perigoso da

eliminação de dados.

O cenário: um arquivo da agência reusado por vários clientes, cujo veículo natural é o modelo de

relatório. Se a eliminação de um cliente alcançasse esse arquivo, ela apagaria o byte de todos, e

um relatório novo de terceiro passaria a exibir "removida a pedido de eliminação de dados" no

lugar de uma imagem que ninguém pediu para remover. Dano silencioso, cruzando clientes, e

irreversível.

CORREÇÃO IMPORTANTE, de 2026-08-13: isto NÃO é risco futuro, ACONTECE. A primeira versão deste

cartão dizia que duas guardas fora da fatia fechavam o caso. Estava errado, e o erro é instrutivo:

a revisão chegou a essa conclusão lendo as duas guardas; a validação executou e mediu o

arquivo do modelo morrendo ao eliminar uma conta. Quem rodou vence quem leu, e esta é a segunda

vez na mesma obra que essa regra decide.

E o dano medido é maior do que o previsto: a lápide que substitui a imagem é por agência,

então todo relatório futuro de outros clientes passa a exibir o aviso de eliminação de dados

por causa de um pedido que não era deles. O dano cruza clientes e alcança quem ainda nem existia

quando o pedido foi feito.

Por isso este cartão passa a ser bloqueante da fatia de eliminação, não sucessor dela.

O que implementar: tornar a proteção deliberada. Ou a eliminação passa a reconhecer arquivo

compartilhado entre clientes e recusa apagá-lo (relatando, nunca em silêncio), ou o caminho que

poderia criar esse compartilhamento ganha guarda própria com o motivo escrito. **O que não vale é

seguir confiando nas duas coincidências.**

Como verificar (teste primeiro): montar deliberadamente o compartilhamento (habilitando o tipo

de bloco no modelo) e confirmar que a eliminação de um cliente não apaga o byte dos outros. Sem

esse teste, a próxima pessoa que mexer nas duas guardas não terá como saber o que quebrou.

Aceite (H1): Dado um arquivo referenciado por mais de um cliente, Quando a eliminação de dados de

um deles roda, Então o arquivo não é removido enquanto houver outro cliente referenciando-o, E a

decisão é relatada, E existe teste que reprova se a proteção sair.

ENTREGUE em 2026-09-22, merge dd6422e no ModularHub, migration 0233 aplicada antes da

imagem e deploy 14/14. Gates plan APPROVED, qa PASS e review APPROVED, os tres no merge.

O comportamento em producao, medido logo apos o deploy, e exatamente o desenhado: o

catch-up rodou no boot, achou a ocorrencia perdida de 21/09 e gravou skipped_expired,

sem emitir o resumo velho (zero notificacoes de digest criadas). "Nao saiu" virou fato

consultavel na tabela em vez de silencio, que era o buraco de origem. E

/api/health/scheduler responde {"ok":true,"atrasados":[]}.

O detector NASCEU CEGO e o qa pegou antes do merge, e esta e a parte que mais importa: ele

media agora - ultima ocorrencia perdida, valor que para job periodico **nunca passa de um

periodo. Com folga de 90 min sobre um job de 60 min, o auto_escalation podia ficar 30

dias parado aparecendo em dia. Era o proprio defeito deste cartao reaparecendo dentro do

detector. Corrigido na causa: ancora na primeira** ocorrencia perdida, mais folga abaixo do

periodo. Provado nas duas pontas (2h e 30 dias) e sem falso positivo em operacao normal.

A armadilha de calibragem que gerou isso fica escrita, porque ela e sutil: a folga tinha

acabado de ser corrigida por um bom motivo (a versao anterior, de "um periodo", cegaria o job

SEMANAL no caso real de 21/09, perdido por 2h44). Acertou para o job longo e abriu buraco no

curto, porque so o caso que motivou a mudanca foi testado.

Decisoes que o cartao carrega: auto_suspension fica sem catch-up de proposito

(recuperar suspensao atrasada suspenderia contas em lote numa hora sem ninguem olhando); o

catch-up e coalescente (buraco de 6 dias num job horario gera 1 execucao, nao 144); e o

detector vive fora do processo, porque dentro dele seria cego exatamente quando o agendador

morre.

Divida NOMEADA, declarada e nao escondida: faltam o selo "atrasado" no /admin/jobs e o

PATCH de catchup_mode/folgas na interface, entao hoje esses valores so mudam por SQL direto, o

que arranha admin-editability-first. E nao existe verificacao de sanidade impedindo um

admin de configurar folga maior que o periodo e reintroduzir o defeito, o que o proprio BUG-01

prova ser possivel.

**Nasceu do plano do {F8-63}, que foi olhar o digest e achou algo maior que o destino do

link.** Medido em 2026-09-21: o ultimo aviso de digest em messages.notifications e de

2026-08-31, e sao ZERO nos ultimos 21 dias, contra 148 no total historico. O

weekly_digest parou de emitir ha tres semanas e o sistema seguiu verde.

Por que isso passou: ninguem monitora AUSENCIA. Aviso que nao chega nao gera erro, nao

aparece em log de falha e nao quebra teste; some em silencio, igualzinho a API que ficou 7 dias

fora com o site respondendo 200. E a mesma familia do {P0-A3}.

O que implementar: primeiro descobrir POR QUE parou (cron, agendamento, excecao engolida ou

mudanca de dependencia), consertar, e so entao decidir o destino do link do digest, que

era a pergunta original. O /alertas e destino defensavel para ele, porque o corpo do resumo

("N alertas pendentes") sai de fetchPendingAlertSources, a mesma funcao que monta a Central;

o que falta e recorte temporal, e esse e o unico ponto que depende do dono.

Observavel: existe um resumo semanal novo depois da correcao, e existe verificacao que

reprova a AUSENCIA dele por mais de uma semana. Reprova consertar a emissao sem deixar o

detector de ausencia, porque foi justamente a falta dele que deixou o defeito viver 3 semanas.

FECHADO em 2026-10-15, com prova. Os 2 modelos F820 sairam em 26/09 ({REC-F-14}, GO do dono). SELECT

em producao (reports.template): total=3, individual sem agencia=0, nome F820=0 (evidencia

/opt/modularhub-evidencias/f8-41/f8-69-select.txt). A guarda contra voltar (CHECK no banco) e do {F8-41}.

Origem: smoke visual do fiscal em producao, 2026-09-24 (P1). Em /relatorios/templates

aparecem "F820 Modelo da Agencia" (ADS 4 PROS) e "F820 Modelo GLOBAL", este Individual SEM

agencia de origem, o que contradiz a regra da propria tela. **Procedencia medida pelo loop (so

leitura):** reports.template 88574064... (company_id nulo, is_global=false) e bb2f87e5...

(ADS 4 PROS), criados no MESMO instante, 2026-08-13 23:43:46 UTC; o nome "F820 Modelo" existiu

no codigo de teste do {F8-20} (commits cb47b1b e b7baa30, 13/08) e depois saiu; o commit

8e17ab8 (14/08 01:12) diz "o ator 14 para de escrever solto em producao". Ou seja: sobra de

uma rodada de teste do {F8-20} que gravou em producao antes da trava. Nenhum relatorio usa os

dois (reports.report com esses template_id = 0). Os default_blocks apontam para assets

(aecb5600..., 096ef77c...) a conferir no storage.

Exclusao em producao passa pelo dono (regra do fiscal): o cartao entrega a medicao completa

(templates, assets e objetos de storage ligados, prova de que nenhum dado real depende deles) e

o pedido de exclusao nomeado; apagar so depois do GO.

GO relatado pelo fiscal (2026-09-24, noite), escopo fechado: so os 2 ids acima, mais os

assets e objetos de storage EXCLUSIVAMENTE deles pela medicao do cartao; dump das linhas em

arquivo de backup antes; prova depois: 0 linhas para os 2 ids, /relatorios/templates sem os

dois, contagem de Individuais = 1. O loop confirma o GO direto com o dono na hora de apagar.

Aceite (H1): Dado a lista de modelos em producao, Quando o Super Admin abre

/relatorios/templates, Entao nenhum modelo de teste aparece, E nenhum modelo Individual existe

sem agencia de origem, provado por consulta e pela tela.

ENTREGUE em 2026-09-27 pelo {SMK-05} do roadmap do ModularHub, merge 02ac516. Mesmo

defeito, mesma fonte: o mapa unico blockTypeLabel (canonical-enums), alinhado aos 16 tipos do

BLOCK_REGISTRY do renderizador, serve a lista de modelos, o Compositor e a criacao de

relatorio; teste de paridade reprova tipo novo sem nome. Os 5 que vazavam agora tem nome.

Origem: smoke visual do fiscal em producao, 2026-09-24 (P2). Em /relatorios/templates a

lista de blocos mistura nomes traduzidos com identificadores internos (section_intro,

reliability, line_chart, donut, action_plan). Print em

00-operacao/projetos-internos/ophub-v2-modularerp/tmp/fiscal-smoke-2026-09-24/ERR-14-15-templates-rotulo-tecnico-viewport.png.

Medir ao pegar: de onde vem o rotulo (mapa de tipos de bloco), quantos tipos estao sem nome

humano, e se o mesmo mapa serve o compositor e o relatorio publicado.

Aceite (H1): Dado a lista de blocos do editor de modelos, Quando o usuario a abre, Entao todo

bloco tem nome humano em portugues e nenhum identificador interno aparece, E um tipo de bloco

novo sem nome reprova um teste.

FECHADO POR RECONCILIAÇÃO em 2026-10-16 (plano plan/f8-68.gate, sem código): o {P0-A4a} cobre os 5

caminhos. Purga e eliminação liberam a posse; apagar conta é barrado pela FK (409) e a eliminação da conta

libera inclusive posse sem byte (I8, depois a conta apaga com 204); não há rota de apagar agência nem

relatório (só SQL, e aí a posse fica de propósito, migration 0258). Observável corrigido: "zero donos sem

relatório" contradiz o desenho (deixaria arquivo vivo sem dono, impossível de eliminar); o certo é "toda

conta tem saída pela eliminação". Produção hoje: 0 donos, 0 relatórios, 0 lápides. Achado sem card: o

texto do 409 diz que há arquivos mesmo quando já sumiram (a saída funciona, a frase é imprecisa).

**Achado durante a limpeza do {F8-41} em 2026-09-22, e e um residuo que nasce de uma guarda

BEM-INTENCIONADA. reports.asset_owner tinha 6 registros, e os 6 eram orfaos**: o relatorio

deles ja nao existia. Todos com sha256, size_bytes e created_by nulos, e

storage.objects vazio, ou seja, eram ponteiros para arquivo que nunca existiu.

Por que acontece: a FK asset_owner_conta_com_arquivo_vivo e ON DELETE RESTRICT e protege

a CONTA de ser apagada enquanto houver dono de arquivo. Mas **nada protege o asset_owner de

perder o relatorio: quando o relatorio cascateia, o registro de dono fica. Entao a propria

limpeza produz residuo**, e produziria de novo a cada apagamento de relatorio, com ou sem

intervencao nossa.

O efeito pratico ja foi sentido: esses orfaos travaram a remocao de uma conta de fixture na

agencia parceira, com a mensagem de que havia "arquivo vivo" quando nao havia arquivo nenhum.

Uma guarda que mente sobre o motivo e pior que uma guarda ausente, porque manda investigar o

lugar errado.

O que implementar: ou o asset_owner cascateia junto com o relatorio, ou existe varredura

que recolhe dono sem relatorio. Decidir qual, e declarar o que acontece com asset_owner cujo

arquivo EXISTE de verdade (sha256 preenchido) quando o relatorio sai, porque ai apagar o

ponteiro sem apagar o arquivo deixa lixo no storage.

Observavel: apagar um relatorio nao deixa registro de dono para tras, e uma consulta por

dono sem relatorio devolve zero. Reprova fechar so limpando os orfaos de hoje: eles ja foram

removidos e voltariam no proximo apagamento.

ENTREGUE em 2026-09-22, merge 2d4efed, migration 0234 antes da imagem, deploy 14/14.

Gates plan APPROVED, qa PASS e review APPROVED, os tres no merge.

Em producao, a cadencia confirma o desenho: em 60 segundos o relay de 15s registrou 4

tiques, o flusher de 30s registrou 2, e os de 60s registraram 1 cada. Os de periodo longo

(imap 5min e os dois diarios) ainda nao bateram e nao aparecem como atrasados, que era o

falso positivo a evitar. /api/health/scheduler responde

{"ok":true,"atrasados":[],"desligados":[]}.

Desenho: control.scheduler_heartbeat, UPDATE-only, 9 linhas para sempre, e foi por isso

que reusar cron_job_executions foi reprovado, ja que so o relay daria 5.760 linhas por dia

numa tabela que ja tem 2.312 sem expurgo. Folga derivada do periodo, clamp(120s, 2h), para

cobrir um espectro de 15 segundos a 24 horas sem cegar o curto nem atrasar o longo.

NAO tem catch-up, e isso foi medido, nao suposto: os oito varrem estado ou fila e se

recuperam sozinhos ao voltar; o reports-schedule ja tinha catch-up coalescente proprio,

escrito antes do {F8-65}. Catch-up aqui teria sido trabalho errado.

Os gates acharam DOIS defeitos, e os dois sao da familia do instrumento que parece medir:

1. O botao "Desligar" da tela nao desligava o job. So mudava a coluna de expectativa,

enquanto o interruptor real vivia em outro lugar: o Super Admin clicava, a tela respondia, e

o agendador continuava rodando. Agora opera o interruptor de verdade e, onde nao pode,

recusa com 409 dizendo onde desligar, em vez de fingir.

2. Em 5 dos 9, um catch interno engolia o erro ANTES do heartbeat. O job podia falhar em

todo tique com o painel verde. Provado ao vivo revogando permissao: erro no log 5 vezes e

last_ok_at subindo, fail_count em zero. Corrigido em duas camadas, **preservando o

isolamento por item: a falha agrega e lanca no fim do tique, e o agendador continua

tentando**. Provado quebrando uma de tres faixas do expurgo: as outras duas commitaram

trabalho real (6 linhas) e so a quebrada contou como erro.

O que PERDEU: cerca de 6.900 atualizacoes por dia numa API ociosa; passa a existir falha do

vigia que nao e falha do job; a superficie publica cresce; e **ninguem ganha historico por

execucao**, entao nao sera possivel datar um buraco depois do fato, como se fez com os 19 dias.

Nasceu do {F8-65}, e e o cartao irmao dele. O agendador do Control nao morreu sozinho: ele e

mais seis vivem no MESMO processo da apps/api e ficaram fora nos mesmos 19 dias

(01-10/07, 07-08/09, 14-20/09): imap-sync, opadmin-export, notif-retention,

event-outbox-relay, reports-schedule, reports-artifact-purge e error-events-purge.

CORRECAO de 2026-09-22, em duas rodadas: sao OITO alem do control, nao seis. Faltavam no

inventario o error-events-purge e o error-events-flusher (lib/error-events.ts, 30s).

Com o control sao NOVE no mesmo processo. Periodos: relay 15s, flusher 30s, control 60s,

opadmin-export 60s, imap 5min, reports-schedule 15min, artifact-purge 1h, notif-retention e

error-events-purge 24h.

E este cartao NAO e sobre catch-up, para nenhum dos oito. Todos varrem estado ou fila

(pendente, expurgo vencido, idade, saida nao entregue) e se recuperam por construcao ao

voltar. O reports-schedule, que parecia o mais critico por disparar relatorio de cliente, **ja

tem catch-up coalescente proprio** (reports-cycle-trigger.ts, janelas nao fechadas mais corte

em um), escrito ANTES do {F8-65} e com o mesmo desenho. O control precisou de catch-up por ser

gatilho temporal puro, cuja ocorrencia perdida nao existe em lugar nenhum depois.

Unica perda sem conserto possivel: o flusher acumula em memoria, e o que esta no buffer

morre com o processo.

O ACHADO QUE REDEFINE ESTE CARTAO, medido no codigo: nenhum dos sete registra execucao.

O control so pode ser auditado porque tem control.cron_job_executions , e foi de la que

sairam os 19 dias. Os outros sete tem apenas setInterval (60s na maioria, 15s no outbox

relay) e nao gravam nada que diga "rodei"; o unico insert deles e o do outbox relay em

hub.webhook_deliveries, que e o trabalho dele e nao registro de execucao.

Logo, isto nao e "estender o detector": e criar a testemunha que nao existe. Sem registro,

nao ha com o que comparar, e a ausencia continua invisivel por construcao.

Cuidado que o cartao carrega para quem implementar: o outbox relay roda a cada 15 segundos,

entao gravar uma linha por tique dariam cerca de 5.700 linhas por dia so dele. E

cron_job_executions ja tem 2.312 linhas sem nenhum expurgo. Registrar execucao aqui nao

pode nascer sendo a proxima tabela que ninguem limpa.

O que NAO aconteceu, medido antes de virar alarme: o reports-schedule e o envio agendado

de relatorio para cliente, e a primeira leitura disto soou como "cliente deixou de receber".

Nao deixou. Medido em 2026-09-22 no mhub-db: reports.report_schedule vazia,

reports.report_job com 0 linhas e reports.schedule_cycle com 0 linhas, nenhum

registro em nenhuma delas, nunca. Nao havia agendamento para executar, entao nao houve perda.

Isso muda o TEMPO VERBAL do cartao, nao a prioridade dele: o risco e futuro. No dia em que

existir o primeiro agendamento de cliente, o mesmo processo pode morrer e ninguem saber, e ai e

entrega a cliente. Cartao que afirma perda que nao houve tem o mesmo defeito de numero que este

projeto passou o dia caindo.

O que implementar: estender aos seis o detector de ausencia que o {F8-65} constroi, que por

desenho vive FORA do processo (dentro dele seria cego exatamente quando o processo morre).

Observavel: cada um dos seis tem periodo declarado e ha verificacao, fora do processo, que

reprova quando qualquer um deles nao roda ha mais de um periodo. Reprova cobrir so o Control, e

reprova detector que viva dentro da apps/api.

FECHADO em 2026-10-16 pelo {P0-A4a} do Hub (merge Hub 7539832, Reports f1c7da5; RF-ADM-024; em

produção). Dry-run, execução idêntica ao dry-run, sentinelas preservadas, trilha sem dado pessoal, falha

fechada com storage fora, lápide 410 e página de conteúdo eliminado no link do retrato.

Cartão novo, achado no planejamento do {F8-07} em 2026-08-08. A rotina que elimina dados

pessoais a pedido percorre as tabelas do módulo, e não existe tabela de arquivos: os arquivos

enviados vivem no sistema de arquivos, referenciados por identificador dentro do bloco. Resultado:

a eliminação roda, relata sucesso, e os arquivos ficam.

RNF-LGPD-001, RF-ING-004, RN-006.

**Enquanto não há criativo nenhum em produção isto é teórico, e é exatamente por isso que dá para

resolver com calma**, mas deixa de ser teórico no dia em que o {F8-07} ligar a inserção. Um

processo que relata sucesso sem ter feito o trabalho é pior que um que falha alto.

O que implementar: a eliminação passa a alcançar os arquivos referenciados pelo que está sendo

eliminado, e relata o que apagou, para a diferença entre "não havia nada" e "não olhei" ficar

visível. Decidir também o que acontece com arquivo referenciado por retrato imutável já publicado,

que é o caso difícil: o retrato não muda, mas o requisito de eliminação existe.

Como verificar (teste primeiro): enviar um arquivo, referenciá-lo, rodar a eliminação e

confirmar que o arquivo saiu do disco e que o relatório da eliminação o menciona; e exercitar o

caso do arquivo referenciado por publicação já feita.

Aceite (H1): Dado um arquivo enviado e referenciado, Quando a eliminação de dados pessoais roda,

Então o arquivo é removido do armazenamento, E o resultado da eliminação declara o que foi removido,

E o caso do arquivo preso a retrato já publicado tem tratamento decidido e registrado.

Rodada 17 (2026-08-14): o conserto porta a porta acabou, porque virou propriedade. Dezesseis

rodadas fecharam uma junção de cada vez, e cada uma nasceu de alguém atravessar a seguinte. O

levantamento por construção mostra por que isso não ia terminar sozinho: das 46 colunas de

identificador das 22 tabelas do módulo, 21 são âncora (a agência da própria linha, ou o pai de

quem a linha se pendura) e 2 não apontam para agência nenhuma; sobram 23 junções que podem

discordar - e 14 delas não tinham guarda de espécie alguma. Medido por efeito, sob o papel que

a produção realmente usa para gravar, tudo em transação revertida: antes, 13 das 14 aceitas

(a décima quarta foi recusada pela chave primária, não por guarda de inquilino); **depois, 0

aceitas e 14 recusadas, com os 6 caminhos legítimos vivos nos dois lados** - inclusive o que

esta fatia inteira existe para proteger, a lápide do relatório já apagado. Entre as 14 estavam a

quinta porta no nível da tabela (override da própria agência apontando relatório alheio, linha

que a vítima não enxerga numa tabela que fala sobre ela, fechada pela política no padrão que a casa

já tinha) e a do nível da função (as duas rotinas de recomendação gravavam o identificador de

relatório sem conferir nada). **A afirmação deixou de ser "as quinze estão conferidas" e passou a

ser "toda junção com inquilino é conferida"** - e ela se monta do catálogo, então coluna nova

aparece sozinha. Provou-se pelo avesso: derrubada a guarda de uma tabela em produção, os dois

casos reprovaram nomeando as duas colunas exatas. O que fica declarado, e é o limite honesto:

o arquivo não tem linha própria - a agência dele é o diretório, e o banco não enxerga disco.

A guarda cobre o que o banco sabe (posse viva ou lápide já existente); arquivo sem nenhum dos dois

ainda é reivindicável pela agência errada. Medido: 8 arquivos, 6 com dono, 2 nessa condição.

Fechar isso pede conferir o caminho no disco, e é cartão próprio.

Retomado em 2026-10-15 pelo {P0-A4a} do ModularHub, fatia F1: o requisito nasceu. O trabalho

das 17 rodadas não entrou em nenhuma main e volta por branch nova, em fatias (F0 leitura do que

já existe em produção, F1 requisito, F2 migrations, F3 posse na escrita, F4 eliminação de arquivo).

A F1 escreveu no DRS o RF-ADM-024 (a eliminação alcança os arquivos e relata o que apagou):

posse registrada na gravação, ensaio que não apaga nada, execução que apaga exatamente o que o

ensaio listou, preservação com motivo do que não é do cliente, falha fechada sem varredura,

um evento de auditoria por execução e lápide (410) no lugar do "não encontrado". O RF-ADM-011

passou a apontar para ele, o RNF-LGPD-002 ganhou corpo e H1, e o modelo de dados ganhou as tabelas

de posse e de lápide.

Decisão do retrato já publicado, pela Regra Zero (uma resposta certa, sem cenário): o retrato

do cliente eliminado não é editado nem mantido com buracos, é eliminado inteiro. O RF-ADM-011 já

manda apagar os snapshots e revogar os links; a imutabilidade do RF-PUB-001 protege contra edição

do rascunho, não contra a eliminação; e a lei não dá base para guardar uma página de resultados

depois do fim do tratamento. O link passa a mostrar a página brandada de conteúdo eliminado (410),

distinta da de link revogado, e os arquivos que ele citava saem do armazenamento. Cópia que já

saiu do sistema (PDF baixado pelo cliente final) não é alcançável, e o requisito declara isso.

Aceite (H1) passa a ser o do RF-ADM-024, que contém e endurece o H1 acima. O Plano de Testes

ganha o item Alfa do RF-ADM-024 quando a F4 fechar. Próximo: F0, depois do {INFRA-21}.

Cartão novo, e ele não nasce de um caso: nasce da TERCEIRA ocorrência do mesmo padrão (2026-08-09).

Uma rota lê o estado do rascunho, faz uma chamada de rede que leva segundos, e grava **substituindo

o conjunto inteiro** a partir do que leu antes. Qualquer escrita que aconteça nessa janela é

sobrescrita em silêncio.

Já custou um Critical, na fatia dos criativos, onde a composição apagava o bloco que o operador

acabara de inserir. Foi corrigido lá, relendo com trava na mesma transação que grava. **As duas

rotas da pesquisa de mercado têm o mesmo desenho e continuam sem conserto**, substituindo o conjunto

de pontos de dado a partir de um retrato lido antes da chamada externa.

RF-CMP-002, RF-ING-006, RN-004.

O que implementar, e o ponto é não consertar caso a caso: as rotas afetadas passam a reler com

trava na transação que grava, como já foi feito na composição. E, porque esta é a terceira vez,

vale uma varredura que encontre o padrão: gravação que substitui coleção inteira derivada de

leitura anterior a uma chamada externa. Consertar as duas conhecidas deixa a quarta nascer igual.

Como verificar (teste primeiro): um teste que reproduza a corrida em cada rota afetada e

reprove sem o conserto (o defeito anterior sobreviveu a testes verdes porque eles exercitavam a

lógica contra dado estático, nunca o fluxo de duas transações); e a varredura acusando um caso

plantado.

Aceite (H1): Dada uma escrita concorrente durante a janela de uma chamada externa, Quando a rota

grava, Então nenhum dado gravado nesse intervalo é perdido, E o padrão de gravação cega é acusado

por varredura quando reaparecer.

FECHADO em 2026-08-10, mergeado (60696d3) e deployado. QA PASS e review APPROVED.

A varredura entregou mais do que o cartão pedia, e é esse o ponto de ter pedido varredura. 13

sítios classificados; 6 com o padrão, dos quais 4 vulneráveis e corrigidos, e **dois deles não

eram nomeados pelo cartão**: criar artefato e regenerar bloco. Conserto caso a caso teria deixado os

dois de pé, com o placar verde.

Prova reconferida sem confiar em relato: o QA reverteu o código e mediu, rota a rota, que os

testes de corrida falham sem o conserto e passam com ele (2, 1 e 2 falhas respectivamente). E

plantou ele mesmo uma rota vulnerável nova, que a varredura acusou.

A guarda mede mecanismo, não etiqueta, e isso veio de uma segunda rodada. Ela nasceu exigindo só

a presença de um marcador de texto. O review apontou que marcador colado sem trava passaria, que é

exatamente o que acontece quando alguém copia o bloco vizinho "para seguir o padrão". Reforçada para

exigir a trava real em código, não em comentário, com o par de casos provado: com trava não acusa,

sem trava acusa.

Um desvio de rota que quase virou dívida, registrado porque a lição é de método. Ao medir o

encanamento, o pacote da API apareceu sem comando de teste, e a leitura apressada foi "os 30

arquivos falham". Estava errado: eles seguem outra convenção, rodam um a um e passam (o

arquivo conferido devolveu 7 de 7). O engano nasceu de apontar o executor errado, e a instrução que

pediu o placar já sugeria a conclusão, o que enviesou quem mediu. Um comando de teste chegou a ser

adicionado e foi desfeito antes do merge: ele faria o projeto reportar 30 falhas inexistentes, e

comando que mostra vermelho falso é pior que comando nenhum, porque ensina a ignorar vermelho. O

problema real virou {F8-33}.

Achados encaminhados como cartão próprio, não como recomendação dentro do gate: {F8-30} (sete

escritas sem trava, sem rede na janela, incluindo a de publicar, número corrigido de seis para sete

pela recontagem do review), {F8-31} (a conexão do banco fica presa durante a IA em três rotas, e

a rota de regenerar já mostra o desenho certo) e {F8-32} (a função de leitura muta a estrutura que

recebe, obrigando todo chamador a uma cópia defensiva que ninguém é lembrado de fazer).

**Cartão novo, nascido do planejamento de {F8-08} em 2026-08-08 e escrito no roadmap em 2026-08-09,

junto da reconciliação do documento. É ele que bloqueia a Fatia B de {F8-08}** (o logo do

cliente por relatório), e enquanto não existir como cartão o bloqueio vive só na cabeça de quem

planejou.

O conflito, medido: o protótipo aprovado desenhou dois portadores de marca na página

pública, com donos distintos: a abertura do relatório é do CLIENTE, e a barra superior é da

AGÊNCIA, com a linha de crédito de quem preparou o relatório. A barra nunca foi construída, e

por isso a marca da agência foi parar no único portador que existe, o do cliente. Consequência: uma

sobreposição de logo do cliente naquele slot apagaria a marca da agência da página inteira,

desfazendo o que {F7-04} entregou de propósito e tornando falso o aceite de RF-ADM-004 para aquele

relatório. É a regressão silenciosa clássica: passaria por plano, teste, revisão e verificação

visual, porque os quatro olham o comportamento NOVO e nenhum pergunta o que sumiu.

A alternativa foi avaliada e descartada, e fica registrada para não voltar: fazer o portador do

cliente preferir o cliente e deixar a agência como reserva no mesmo slot não custa barra nova, mas

numa página com logo de cliente a marca da agência desaparece do produto inteiro. Trocar uma

promessa cumprida por outra não é entregar.

RF-ADM-004, RF-CUR-004, RN-020 item 4; artefato {ART-SCR-03} do Inventário.

O que implementar: a barra superior no leitor público, alimentada exclusivamente pela

identidade congelada no retrato publicado (nunca leitura ao vivo do cadastro, que contradiria

RN-020 item 3), com logo na proporção natural, estado sem logo, contraste no mesmo mínimo do resto

da página e recolhimento em tela estreita. Ficha completa em {ART-SCR-03}.

Como verificar (teste primeiro): um relatório publicado real exibe a marca da agência na barra

superior; a proporção renderizada do logo é conferida contra a proporção natural do arquivo, não a

olho; um relatório publicado ANTES desta entrega continua abrindo sem erro; e o caso de agência sem

logo cai no nome em texto em vez de espaço vazio.

Aceite (H1): Dado um relatório publicado, Quando o cliente final abre o link, Então a barra

superior exibe a marca da agência que preparou o relatório, E a marca vem da identidade congelada

no retrato e não do cadastro ao vivo, E o logo é exibido na proporção natural, E a abertura do

relatório permanece disponível como portador do cliente.

FECHADO em 2026-08-10, mergeado (fa00cf0) e deployado. Migration 034 congela também o nome da

agência no retrato, ao lado do logo que já era congelado. QA PASS e review APPROVED, os dois com o

Check 0 explícito: a marca da agência mudou de lugar sem sumir e sem duplicar. Contagem de

imagens na página inteira igual a uma no caso com logo e zero nos demais, nenhuma órfã no lugar

antigo. A abertura ficou vaga de propósito, que é o que este cartão existia para entregar: a

Fatia B de {F8-08} está destravada.

O defeito que só apareceu porque alguém olhou: a barra nasceu como irmã do documento, **fora do

container onde as variáveis de cor existem**, e ficou sem cor nenhuma (fundo transparente, texto

preto). O próprio autor achou no smoke e corrigiu movendo-a para dentro. Medido depois do conserto:

contraste 15,97:1 no nome e 6,91:1 na linha de crédito, logo quadrado de 900 por 900 renderizado

como quadrado, sem sobreposição com o título nem em tela grande nem em celular. O review deixou o

risco nomeado: nada automatizado impede uma fatia futura de pôr transformação no container e

quebrar a fixação da barra.

Divergência de julgamento entre os dois gates, registrada porque ela é a parte interessante. O

preview do compositor e o PDF continuam mostrando o logo da agência na abertura. O review chamou de

dívida nova, da mesma família que a fatia da cor pagou; o QA respondeu que não viola requisito

nenhum, porque RN-020 item 4 e a ficha {ART-SCR-03} escopam a regra à página pública. **Os dois

estão certos no que afirmam**: não há violação de spec, e ainda assim o operador aprova uma abertura

e o cliente recebe outra. Virou {F8-28}, atrás de {F8-08} na fila, e lá está registrado o achado

que nenhum dos dois gates viu: o PDF não tem barra superior, então quando o logo do cliente

ocupar a abertura a marca da agência some do PDF por completo se ninguém decidir onde ela vai.

Achado de infra durante o deploy, corrigido no mesmo ato: o leitor subia avisando que

READER_ASSET_SECRET não estava configurada e gerava um segredo por processo. As URLs de imagem

são assinadas a cada requisição, então nenhum retrato guardado quebrou; o que quebra é quem está com

a página aberta no instante do restart, e (o caso caro) qualquer futuro segundo leitor, porque

duas réplicas assinariam com segredos diferentes e as imagens falhariam de forma intermitente, do

jeito mais difícil de diagnosticar. O segredo era previsto no desenho e nunca tinha sido

provisionado. Provisionado e o container recriado; o aviso saiu do log.

Cartão novo, achado no planejamento de {F8-08} em 2026-08-08, escrito em 2026-08-09. As páginas

que respondem por um link revogado ou expirado resolvem a identidade ao vivo, lendo o cadastro,

em vez de usar a identidade congelada no retrato. E a precedência que elas aplicam **já hoje

diverge** da que a publicação aplica: elas não têm o degrau do padrão da agência e caem direto na

cor padrão do renderizador.

**Com a sobreposição por relatório ({F8-08} Fatia A), isso passa a ser a terceira precedência viva

no sistema**, exatamente contra RF-CUR-012, que existe para haver uma só.

RF-CUR-012, RN-020, RF-REN-006.

Por que ficou fora de {F8-08}: são páginas que, por definição, não estão mostrando relatório

nenhum. Não é desculpa para deixar sem dono, que é o que {F5-09} acabou de cobrar.

O que implementar: essas páginas passam a resolver identidade pelo mesmo ponto único das

demais, ou declaram, no próprio código e neste cartão, por que a identidade delas é deliberadamente

outra. Uma das duas, nunca o silêncio atual.

Como verificar (teste primeiro): revogar um link de um relatório cuja cor veio de sobreposição e

conferir que a página de revogado usa a mesma cor que a página do relatório usava, ou a cor

declarada como deliberada; e o mesmo para um link expirado.

Aceite (H1): Dado um link revogado ou expirado de um relatório com identidade resolvida, Quando

alguém o abre, Então a identidade exibida vem do mesmo ponto único de resolução do restante do

sistema, E não existe uma segunda precedência de identidade viva no produto.

FECHADO em 2026-08-10, mergeado (ef77eb9) e deployado. QA PASS e review APPROVED. Saída

escolhida: a primeira, ponto único, lendo a identidade já congelada no retrato.

A pergunta que parecia estrutural se dissolveu ao ser medida. O cartão tratava como ponto difícil

"de onde vem a identidade quando não há relatório para mostrar". A resposta: **esse caso não

existe**. Revogar exige que o relatório esteja publicado, e expirar só é avaliado depois disso.

Então sempre há retrato, com a identidade já resolvida. O único estado sem identidade é o de link

que nunca existiu, e ele segue como estava, por desenho.

Prova direta de que a leitura ao vivo morreu: o QA revogou e expirou relatórios reais e, **depois

disso**, alterou o cadastro da agência e do cliente no banco. As páginas continuaram mostrando a cor

e o nome congelados. É o teste que separa "não lê mais ao vivo" de "por acaso coincide".

O defeito que ninguém tinha pedido para procurar, e é o mais grave desta fatia: essas páginas

nasceram sem cor nenhuma, desde a Fatia 5. O elemento principal nunca carregou a classe a que as

variáveis de cor são escopadas, então a identidade era declarada e não alcançava nada. Meses no ar

assim. Foi achado de raspão, por quem tinha ido mexer em identidade por outro motivo, e

confirmado por medição do estilo aplicado, não pela folha declarada.

É a terceira ocorrência da mesma armadilha em dois dias ({F8-21}, esta, e a dormente em {F8-35}).

Por isso a quarta não vai ser consertada uma a uma: virou {F8-36}, que varre o conjunto.

Achado de precedência que o review mediu e o cartão não sabia: essas páginas tinham **dois dos

quatro degraus** de resolução de identidade. Ao unificar, elas ganharam o degrau do padrão da agência

que faltava: mudança de comportamento visível, intencional e coberta por teste.

FECHADO em 2026-08-18. Placar REMEDIDO com o critério comportamental do próprio cartão

(chamar a varredura e ler o veredito, nunca busca textual): das 7 formas, **5 já passavam e 2

reprovavam** - o cartão registrava 4 e 3, e a diferença é a data por extenso ("Junho de 2026"),

fechada horas antes na mesma sessão pela onda OP abaixo. As duas que faltavam são as formas de

ordinal escrito SEM o indicador sobrescrito: "Criativo 3" (o exemplo literal da nota do

requisito) e "3o criativo".

A isenção não nasceu de lista nova, que seria a inclusão nomeada que este projeto já pagou

caro: o nome da peça vem de ENTITY_PHRASES_FOR_ORDINAL, achatado do MESMO ENTITY_VOCABULARY

que classifica a entidade da tupla de identidade - entidade nova entra nos dois usos de uma vez,

e o teste percorre o vocabulário inteiro em vez de citar quatro nomes.

Controle negativo por forma nova, como o cartão exige: o número só é isento COLADO ao

substantivo. "Criativo 3 trouxe 340 leads" passou a acusar SÓ o 340 (antes acusava "3" e "340"),

e "O criativo campeão do mês trouxe 3 vendas" continua acusando o 3.

Suíte 1613 verde; merge 403899f em main, deployado.

**Cartão novo, e ele nasceu ao contrário do que o planejamento previa: a premissa do plano estava

MORTA e a medição achou o defeito oposto.** O plano de {F8-08} registrou a suspeita de que o

perímetro da disciplina de número derivava de uma segunda lista curada, deixando a abertura do

relatório de fora da varredura. **Medido em 2026-08-09 no código vivo: essa suspeita é falsa e já

tinha sido corrigida por {F18-20}** (o perímetro deriva dos campos editáveis, e a abertura devolve

os quatro campos de texto dela). Controle negativo executado: uma abertura com um número de métrica

digitado à mão reprova, como deve.

O que a mesma medição encontrou, e é defeito vivo: a varredura reprova casos que o próprio

RF-CUR-011 isenta com todas as letras. O requisito diz, no aceite, que "uma data, um ordinal ou uma

faixa de segmentação no mesmo campo não reprovam", e a nota dele cita nominalmente um exemplo que

hoje reprova.

Contagem. Universo: as três classes que o aceite de RF-CUR-011 isenta nominalmente (data,

ordinal, faixa de segmentação), exercitadas por forma de escrita. Critério: COMPORTAMENTAL,

chamando a varredura de proveniência com a legenda como único conteúdo e lendo o veredito dela,

nunca busca textual no código. Placar: **7 formas exercitadas, 4 passam e 3 reprovam, e 4 mais 3

fecham em 7.** Passam (lado negativo, lido por inteiro): data com barras, data no formato de ano

com traços, ordinal com indicador ordinal sobrescrito, e faixa de idade com hífen. Reprovam: um

ordinal escrito só com o dígito ("Criativo 3", que é o exemplo literal da nota do requisito), o

mesmo ordinal com a letra em vez do indicador sobrescrito, e uma data por extenso cujo ano é lido

como métrica ("Junho de 2026"). Evidência de 2026-08-09, medida contra a linha principal do

repositório do renderizador na mesma data, portanto posterior a {F18-20} e não herdada dele.

O requisito que REPROVA este defeito, com o texto literal: RF-CUR-011, aceite, cláusula "E uma

data, um ordinal ou uma faixa de segmentação no mesmo campo não reprovam".

O que implementar: a isenção passa a cobrir as três classes pela FORMA como as pessoas

realmente escrevem, e não só pelos formatos que o conjunto de padrões livres já reconhece. O

cuidado é o de sempre e está no próprio requisito: alargar a isenção não pode virar "qualquer

dígito passa", senão o defeito central volta pela porta da frente. Cada forma nova aceita nasce com

o par de controle: uma que passa e uma métrica vizinha que continua reprovando.

Como verificar (teste primeiro): as 7 formas do placar acima viram casos de teste, as 3 que

hoje reprovam passam a passar, as 4 que passam continuam passando, e um controle negativo por

forma nova prova que a métrica equivalente continua sendo reprovada.

Aceite (H1): Dada uma legenda contendo uma data, um ordinal ou uma faixa de segmentação em

qualquer das formas exercitadas, Quando a varredura de proveniência roda, Então nenhuma delas

reprova, E uma métrica escrita à mão no mesmo campo continua reprovando, E cada forma isenta tem o

seu controle negativo no conjunto de testes.

Cartão novo, achado no planejamento de {F8-08} em 2026-08-08, escrito em 2026-08-09. O retrato

publicado grava, honestamente, de onde veio a cor do relatório (sobreposição, ficha do cliente,

padrão da agência ou lacuna). Nenhuma tela mostra isso. O aviso que existe de verdade é o de

tom de voz; o de cor, que RF-ADM-006 exige em palavras ("usando identidade padrão da agência"),

não tem superfície.

É a família "peça pronta que ninguém aciona", que este projeto já pagou várias vezes. O campo é

gravado, a distinção entre os valores foi desenhada de propósito (é ela que separa "herdou porque a

ficha está vazia" de "o operador escolheu"), e o produto não expõe a diferença que justifica o

campo existir.

RF-ADM-006, RF-CUR-012, RN-020 item 1.

O que implementar: o compositor e a página de publicação exibem a procedência da cor em

linguagem humana, e o aviso de identidade padrão da agência aparece quando é esse o caso, do mesmo

jeito que o de tom de voz já aparece. Sem inventar canal novo: é a mesma superfície de aviso que já

existe.

Como verificar (teste primeiro): um relatório de cliente com ficha vazia mostra o aviso de

identidade padrão da agência; um com ficha preenchida não mostra; e um com sobreposição de

relatório mostra que a cor foi escolhida naquele relatório, nunca confundido com herança.

Aceite (H1): Dado um relatório cuja cor veio do padrão da agência, Quando o operador o abre no

compositor ou vai publicar, Então o aviso de identidade padrão da agência aparece, E um relatório

com cor declarada pela ficha do cliente não exibe esse aviso, E um relatório com cor escolhida nele

mesmo é apresentado como escolha e não como herança.

**Cartão novo, escrito em 2026-08-10, fechando a decisão de produto {Q9} do Questionário de

Elicitação.** O dono decidiu em uma frase: "o nome do relatório ser o título do relatório". Não

existem dois nomes a unificar, e essa é a descoberta que reescreve o cartão: **o banco tem um único

campo de título (reports.report.title), o operador o escreve, e ele não alcança a página

pública por caminho nenhum**. O retrato imutável do publish não o copia, e o que o cliente final lê

no topo do documento vem do card de compartilhamento ou de um texto genérico quando esse card não

foi preenchido. Renomear um relatório é, hoje, gesto de organização interna que o cliente nunca vê.

A pergunta nunca teve duas respostas legítimas, e ficou meses no Questionário como se tivesse.

O documento chama-se relatório, o operador dá nome a ele, e o cliente abre a página: o nome é o

título. Registrar isso como decisão pendente foi transformar trabalho meu em pergunta do dono.

RF-CUR-011, e o próprio DRS já escreveu a consequência (§ RF-ADM sobre renomear): *"se o título

passar a chegar à página pública, ele entra no perímetro no mesmo ato"*. Ou seja, este cartão não é

só encanamento. Ele coloca o título dentro da disciplina de número, ao lado dos campos

editáveis dos blocos. Título com número cru passa a reprovar a publicação como qualquer outro

texto editável, e essa metade é a que não pode ser esquecida: ligar o caminho sem ligar a guarda

abriria um buraco na única trava que separa número com dono de número inventado.

Cuidado com o retrato imutável: relatório já publicado não muda de título retroativamente. O

título vai para o retrato no ato do publish, como o logo e a cor já vão; publicação antiga, sem o

campo no retrato, continua renderizando pelo caminho de hoje, sem quebrar.

O que implementar: o título passa a ser copiado para o retrato no publish; a página pública o

usa como título do documento, com o texto genérico permanecendo só como reserva de retrato antigo;

e a varredura de proveniência passa a cobrir o título junto dos demais campos editáveis.

Como verificar (teste primeiro): publicar um relatório com título escrito pelo operador e abrir

a página pública anônima, com olhos, em tela grande e celular; publicar um com número cru no título

é recusado, nomeando o título como origem da recusa; um retrato publicado antes desta mudança

continua abrindo sem quebrar; e renomear um relatório já publicado não altera a página no ar até

que ele seja publicado de novo.

Aceite (H1): Dado um relatório cujo operador escreveu o título, Quando o cliente final abre o

link público, Então o título que ele lê é o que o operador escreveu, E um título com número sem

origem declarada recusa a publicação apontando o título, E um relatório publicado antes desta

mudança continua abrindo, E renomear depois de publicado só alcança o cliente na publicação

seguinte.

FECHADO em 2026-08-10, mergeado (b97c4cc no pacote, b7c3fb2 no Hub) e deployado. QA PASS e

review APPROVED. **A decisão de produto que estava parada há meses no Questionário virou produto no

mesmo dia em que foi respondida.**

As duas metades entregues juntas, que era a exigência: o título é congelado no retrato no ato do

publish e usado como título do documento que o cliente abre; e o título **entrou na disciplina de

número**: título com número sem origem recusa a publicação. Ligar o caminho sem ligar a guarda

abriria um buraco na única trava que separa número com dono de número inventado.

Prova de que a guarda reprova de verdade: o QA reverteu a chamada do gate no worktree dele e

o teste caiu: publicou com 200 e gravou o número cru no retrato. Restaurou e voltou a reprovar.

Sem essa reversão, o teste provaria apenas que o caminho feliz funciona.

A decisão delicada, medida e aceita: o título não pertence a bloco nenhum, então o mecanismo do

{F18-21} (cruzar contra os dados do bloco) não tem contra o que cruzar. Escolha: recusar, o mesmo

tratamento que o contexto isolado da pesquisa de mercado já usa. Consequência real, medida pelo QA:

um código de peça que passa livre dentro de um bloco é recusado no título. Julgado aceitável

porque nada é cortado em silêncio: a publicação para, a violação é nomeada, e o operador ajusta

antes de publicar. É diferente do caso da pesquisa de mercado, onde o texto some sem aviso.

Retrato imutável provado nos dois sentidos: dois relatórios publicados antes desta fatia,

sem o campo no retrato, abrem em 200 e caem no texto genérico; e renomear depois de publicado só

alcança o cliente na publicação seguinte. O texto do card de compartilhamento continua vencendo

onde existe, verificado ao vivo, não por leitura de código.

Premissa minha corrigida pelo review: eu havia pedido para conferir a coerência de quatro

migrations sobre a função de publicação. São duas. As outras mexem na resolução de identidade.

O review mediu antes de responder em vez de aceitar o enunciado.

Achados encaminhados como cartão próprio: {F8-39} (o servidor nomeia onde está o número recusado

e a tela não mostra, e esta fatia acrescentou o título como mais uma origem no mesmo balde

indiferenciado) e {F8-38} (o resolvedor do card de compartilhamento, pronto, testado, sem chamador,

e com texto padrão que diverge do que produção usa).

**Cartão novo, medido em 2026-08-10 durante a decisão do {F8-26}, e ele é um achado colateral: o

defeito não pertence ao cartão que o encontrou.** A lista de relatórios vive dentro da ficha do

cliente, agrupada por ano, e cada linha diz mês, visualizações e comentários. **O mês exibido é o

da publicação** (published_at), e o agrupamento por ano também. A tabela guarda o período coberto

em campo próprio (reports.report.period), e nenhuma das duas informações da tela vem dele.

Por que isso mente, e não é só imprecisão: um relatório de dezembro publicado em janeiro

aparece listado sob 2027, escrito "janeiro". Quem procura o fechamento do ano passado não o

encontra onde ele deveria estar. Quanto mais tarde a agência publica, mais a lista erra, ou seja,

o erro cresce justamente quando o operador mais precisa se achar.

É irmão do {F13-03} (duas contagens divergentes de visualização): dado existe, tela desenha

outro, e ninguém percebe porque os dois coincidem no caso comum, a publicação em dia.

O que implementar: a lista passa a exibir e agrupar pelo período coberto, com a data de

publicação preservada onde ela é a informação certa (o histórico de publicação), nunca substituindo

uma pela outra em silêncio.

Como verificar (teste primeiro): um relatório cujo período coberto e mês de publicação caem em

anos diferentes é listado sob o ano do período coberto; um relatório ainda não publicado continua

aparecendo na lista, sem sumir por não ter data de publicação.

Aceite (H1): Dado um relatório que cobre dezembro e foi publicado em janeiro do ano seguinte,

Quando o operador abre a ficha do cliente, Então ele aparece agrupado no ano do período coberto e

rotulado com esse período, E um relatório sem publicação continua visível na lista.

ESCOPO AMPLIADO em 2026-08-10, durante a construção, e a ampliação é deliberada. A obra achou o

mesmo defeito no portal do cliente (ReportsPortalPage.tsx): o mesmo par exato, lê

period_start e formata published_at. Duas superfícies, uma raiz. O cartão passa a cobrir as

duas.

Por que não virou cartão separado: o portal é a tela que o cliente final abre. Fechar a

lista da agência e deixar o portal para depois inverte a prioridade (quem paga continuaria vendo

dezembro listado sob 2027) e cai na regra que este projeto já pagou várias vezes: **guarda que

cobre só parte do conjunto não guarda**, porque a metade descoberta herda o placar verde da metade

coberta. Junto veio a exigência de uma grafia só de período no produto inteiro: duas cópias da

mesma formatação divergem em poucos meses.

Aceite adicional (H1): Dado o mesmo relatório de dezembro publicado em janeiro, Quando o

cliente final abre o portal dele, Então o período que ele lê é o coberto e não o de publicação, E a

grafia do período é a mesma nas duas telas.

Achado colateral registrado e NÃO consertado aqui, de propósito: a página da ficha do cliente

transborda horizontalmente em celular, e a obra provou que é anterior e independente desta

mudança (um cartão que ela nunca tocou transborda igual). Merece cartão próprio, não carona numa

branch de outro assunto.

FECHADO em 2026-08-10, mergeado (9601b49) e deployado. QA PASS e review APPROVED, nas duas

superfícies. A varredura fechou em 2 ocorrências, medidas por três partes independentes com o

mesmo número.

O defeito que quase escapou, e foi o review quem viu: a primeira entrega passou a agrupar

pelo período e continuou ordenando pela data de publicação: ano certo, ordem errada dentro

dele. Seria o mesmo defeito do cartão deslocado do agrupamento para a ordem, e fecharia a fatia com

o sintoma vivo. Corrigido no banco (a ordenação é do banco, a da tela é redundância) e provado pelo

QA por três caminhos: consulta direta, requisição real e a tela.

A prova de mecanismo foi feita duas vezes, revertendo: o QA trocou o código pelo da main e viu

os quatro testes caírem mostrando o mês errado, e reproduziu a ordenação antiga no banco para ver a

inversão acontecer. Nenhum dos dois lados foi aceito por relato.

Achado colateral que reescreveu outro cartão: o QA observou que a formatação de período usada no

processamento também alcança a abertura do relatório publicado. Fui medir: **oito retratos

publicados guardam o período como 2026-06-01 a 2026-06-30, e o renderizador pinta** isso na

página que o cliente final abre. O {F8-34}, que tinha nascido como detalhe de tela interna, passou a

ser cartão de página pública. **Um comentário mergeado nesta própria fatia afirma que aquela

formatação "nunca é renderizada para o usuário", e é falso**. Corrigi-lo faz parte do {F8-34}.

Cartão novo, escrito em 2026-08-10, nascido do review do {F8-21}, que perguntou explicitamente

se a divergência era decisão coerente ou dívida nova, e concluiu dívida. Registrado aqui porque

nota em mensagem de commit não é fila de trabalho: some.

O que diverge. Depois do {F8-21}, a marca da agência vive na barra superior da **página

pública e a abertura fica livre para o logo do cliente. Mas o preview do compositor** e o

PDF continuam desenhando o logo da agência na abertura, pelo caminho antigo. São três

superfícies do mesmo relatório mostrando duas coisas diferentes.

Por que isso é caro, e não é preciosismo. O preview existe para o operador aprovar o que o

cliente vai receber. Se ele aprova uma abertura e o cliente abre outra, o preview deixou de ser

prova e virou ilustração. **É a mesma família de defeito que a fatia da cor já pagou neste

projeto** ({F8-08a}): a prévia desenhava com cor fixa enquanto a página publicava com a cor real,

e ninguém viu por semanas porque as duas coincidiam no caso comum.

O PDF é o caso mais grave dos dois, porque ele não tem barra superior nenhuma: quando o logo do

cliente ocupar a abertura, a marca da agência desaparece do PDF por completo se ninguém decidir

onde ela vai. Fatia que trate só o preview e esqueça o PDF resolve metade e cria um sumiço.

Depende de {F8-08} (a metade do logo do cliente): as duas superfícies só têm o que desenhar na

abertura depois que aquele cartão fechar. Enquanto ele não fechar, este fica atrás dele na fila.

RF-ADM-006, RN-020.

O que implementar: preview e PDF passam a mostrar a mesma abertura que a página pública, e a

marca da agência ganha lugar declarado no PDF, já que ali não existe barra superior. Onde exatamente

é decisão de desenho a tomar contra o mockup aprovado, não a inventar no código.

Como verificar (teste primeiro): o mesmo relatório publicado, aberto nas três superfícies com

olhos, mostra a mesma abertura; e o PDF exibe a marca da agência em lugar declarado, nunca sem ela.

Aceite (H1): Dado um relatório publicado com logo de cliente e logo de agência, Quando ele é

aberto no preview do compositor, na página pública e no PDF, Então a abertura é a mesma nas três,

E a marca da agência aparece em todas as três, E em nenhuma delas as duas marcas ocupam o mesmo

espaço.

FECHADO em 2026-08-10, mergeado (8f78726 no pacote, a136f78 no Hub) e deployado. QA PASS e

review APPROVED, os dois na segunda rodada.

A solução foi um par, não uma cópia: a barra fixa continua sendo do leitor (não faz sentido num

documento paginado), e nasceu um selo estático para o preview e o PDF. **No PDF a marca da

agência foi para o topo da primeira página**, dentro do documento. Era o risco central do cartão,

porque ali não existe barra superior e a marca sumiria por completo quando a abertura passasse a ser

do cliente.

O QA olhou as quatro combinações (agência com e sem logo, cliente com e sem logo) **nas três

superfícies**, com fixtures reais e um PDF gerado de verdade, página por página. Confirmou o selo só

na primeira página, sem duplicar, e retrato antigo abrindo nas três.

Três correções vieram do review, e a terceira é a mais instrutiva:

1. As duas marcas tinham o mesmo texto em duas implementações, sem nada garantindo paridade.

Virou fonte única para a regra, com cada uma mantendo só a própria apresentação.

2. O recorte do selo na tela falharia calado se a marcação mudasse. Agora o servidor informa se

injetou, a tela compara, e diverge alto. O review conferiu que as duas pontas são **de fato

independentes**: uma mede antes da injeção, a outra reparseia o entregue.

3. O módulo novo nascia INVISÍVEL à varredura de cor construída horas antes ({F8-36}). Ela

descobria módulos por qual função chamavam, e o selo não a chamava. **A varredura foi ampliada

para descobrir pelo que o módulo PRODUZ**, com o alcance medido: 4 módulos, sem ruído.

É o mecanismo se corrigindo no mesmo dia em que nasceu, e por um caso real em vez de hipótese:

o primeiro módulo criado depois dele já caiu no furo que o review daquela fatia havia declarado como

limite aceito.

Erro meu na validação do deploy, registrado porque quase virou alarme falso: meu comando conferia

o pacote servido contra o de disco pegando o primeiro em ordem alfabética, e o build produz dois

arquivos com o mesmo prefixo. Medi de novo: os dois são do mesmo build, o menor é fragmento

compartilhado referenciado pelo principal, e o documento aponta para o certo. **O comando de

verificação estava errado, não o deploy.**

Cartão novo, escrito em 2026-08-10 a partir do número medido pela varredura do {F8-25}, e ele

nasce por um motivo de método: o achado já estava anotado no código como defeito conhecido, e

comentário em arquivo não é fila de trabalho. Ninguém abre o repositório procurando dívida; abre o

roadmap. Enquanto ele viveu só como comentário, foi redescoberto por três obras diferentes.

O conjunto, medido, e o número foi corrigido antes de este cartão nascer: dos sítios que

substituem o rascunho por inteiro, 6 têm o padrão do {F8-25} (rede na janela) e 7 não têm:

reordenar blocos, editar propriedades, alternar visibilidade, estilo, tema, identidade e

publicar. Esses sete leem, modificam em memória e gravam de volta sem trava nenhuma, só que

a janela entre ler e gravar é curta porque não há chamada de rede dentro dela.

O sétimo apareceu só na recontagem do review, e ele é o mais sensível da lista: publicar é o ato

que congela o retrato. A obra tinha contado seis; o review recontou e achou sete. Registrado aqui

como sete porque foi o número medido por último, e a obra foi avisada para conferir e reportar

divergência em vez de adotar.

Janela curta não é janela fechada, e é isso que separa este cartão de "não é problema". Duas

requisições simultâneas do mesmo operador em duas abas, ou dois operadores da mesma agência

editando o mesmo relatório, e uma das duas edições some sem erro. O produto é multiusuário por

desenho: agência tem equipe.

Por que fica atrás do {F8-25} e não junto: aquele cartão tinha sintoma medido e prova de corrida

reproduzível; este tem risco estrutural com probabilidade menor. Misturar os dois teria inchado uma

fatia que já entregou quatro consertos, dois deles fora do que o cartão nomeava.

O que implementar: a mesma forma de trava já usada nos outros seis lugares: releitura sob trava

dentro da transação que grava. Uma forma só: se ao chegar aqui houver dialetos diferentes no

repositório, unificar faz parte da fatia, senão o próximo sítio copia o dialeto errado.

Como verificar (teste primeiro): para cada uma das seis rotas, duas escritas concorrentes de

campos distintos preservam as duas; o teste falha com o código de hoje e passa com o conserto.

Aceite (H1): Dado dois operadores da mesma agência editando o mesmo relatório ao mesmo tempo,

Quando cada um altera uma coisa diferente, Então as duas alterações sobrevivem, E nenhuma

desaparece sem erro.

FECHADO em 2026-08-10, mergeado (a8ec37b) e deployado. QA PASS e review APPROVED, os dois na

segunda rodada. Sete rotas travadas; a varredura agora conta 13 escritas sob trava e nenhuma sem.

A primeira entrega estava errada no lugar que mais importava, e os dois gates acharam sozinhos.

A rota de publicar relia sob trava apenas o card de compartilhamento. Blocos, números, tema e

identidade (o retrato inteiro) continuavam vindo sem trava, alimentando as quinze verificações

e a gravação final. Consequência dupla: edição concorrente sumia do publicado em silêncio, **e o

produto publicava um retrato que nenhuma verificação tinha examinado**, no ato que congela o

documento para o cliente.

A prova do QA é a melhor evidência produzida nesta sessão, e não é leitura de código: ele abriu

uma transação que gravava o tema e a segurou; disparou o publish; confirmou a transação no meio da

janela. Resultado antes do conserto: o rascunho tinha o tema novo, e **o retrato publicado saiu sem

ele, sem erro nenhum**. Depois do conserto, a edição sobrevive nos três campos.

**Travar a porta menor e deixar a maior aberta é o padrão que quase fechou este cartão com o placar

verde**: o card de compartilhamento estava protegido, a suíte passava, e o defeito continuava vivo

no mesmo endpoint.

Segundo defeito, que só um teste bem construído pega: a rota de estilo devolvia o bloco pelo

índice anterior à trava. O teste original não o encontrava porque o escritor concorrente **não

reordenava** a lista: os dois índices coincidiam justamente no caso testado. Reescrito para

reordenar e conferir o corpo da resposta, ele falha sem o conserto.

O custo foi declarado e verificado, não alegado: a trava passou a ser segurada durante toda a

fila de verificações. Isso só é aceitável porque publicar não faz chamada de rede nem de IA.

Review e QA confirmaram varrendo o corpo das verificações e dos auxiliares, sem encontrar nenhuma. Se

algum dia entrar uma, esta decisão vira o risco de conexão presa que outra fatia de hoje levantou.

Achados encaminhados como cartão próprio: {F8-42} (a trava de título mergeada hoje reprova uma

fixture antiga, e nasceu invisível) e o placar real da suíte da API, registrado em {F8-33}.

Cartão novo, nascido pequeno e MEDIDO grande no mesmo dia (2026-08-10). Ele começou como achado

menor do review do {F8-27}: o compositor mostra as datas no formato do banco. O QA da mesma fatia

observou que a formatação suspeita também alimenta a abertura do relatório, e fui medir.

O que a medição achou, e muda a natureza do cartão: a abertura do relatório publicado exibe

o período assim: 2026-06-01 a 2026-06-30. Confirmado nos dois extremos, não por leitura de código:

os retratos guardam essa forma, e o renderizador a pinta como texto visível na faixa de

informação da abertura (render-blocks.mjs, o trecho que emite o período do bloco de abertura). Ou

seja, não é uma tela interna do operador: é a página que o cliente final abre.

NÚMERO CORRIGIDO, e o erro foi meu, do tipo mais bobo e mais fácil de repetir. A primeira redação

dizia "oito retratos publicados". Oito era o LIMITE da minha consulta, não a contagem. Li o

tamanho da amostra como se fosse o universo. O QA foi conferir e devolveu o número certo. Medido de

novo, sem limite: **12 retratos no total, 9 com período gravado, e 2 relatórios em estado publicado

hoje.** Os três números respondem a perguntas diferentes, e misturá-los é o que produziu o erro.

Por que ninguém viu: a data está correta. É o período certo, do relatório certo. Só está

escrita para uma máquina ler, na peça mais visível do documento, e nenhuma trava reprova texto

certo em formato errado.

Uma afirmação FALSA foi mergeada hoje junto do {F8-27}, e ela é o motivo de este cartão quase ter

nascido pequeno: o comentário da nova fonte única de grafia diz que aquela formatação "nunca é

renderizada para o usuário". É renderizada, na página pública. **Corrigir esse comentário faz parte

desta fatia**: comentário que afirma fato errado desinforma pior que comentário nenhum, e este

projeto já foi mordido por isso mais de uma vez hoje.

O conjunto, para não consertar de novo pela metade: são três superfícies com o período em

formato de máquina: a abertura do relatório publicado (a que importa), o PDF, que compartilha o

renderizador, e a tela do compositor. O {F8-27} criou uma fonte única de grafia; toda superfície

fora dela é uma segunda grafia esperando divergir.

O que implementar: o período chega às superfícies já na grafia humana, vindo da fonte única, sem

que cada tela formate por conta própria. Onde o dado é congelado no retrato, decidir explicitamente

se a grafia entra no retrato ou é aplicada na exibição. Retrato antigo, com a forma de máquina,

não pode quebrar.

Como verificar (teste primeiro): publicar um relatório e abrir a página pública com olhos,

confirmando que a abertura traz o período em linguagem humana; o mesmo no PDF e no compositor; e um

retrato publicado antes desta mudança continua abrindo.

Aceite (H1): Dado um relatório publicado com período preenchido, Quando o cliente final abre o

link, Então a abertura mostra o período em linguagem humana, E o PDF e o compositor mostram a mesma

grafia, E um retrato publicado antes desta mudança continua abrindo sem quebrar.

FECHADO em 2026-08-10, mergeado (4437c64) e deployado. QA PASS e review APPROVED. O QA fez o

que o construtor não conseguiu: subiu tudo descartável e olhou (página pública anônima em tela

grande e celular, PDF real gerado, e o compositor). Sem isso, este cartão teria fechado no papel,

porque o defeito dele só existe para quem olha.

Terceira superfície achada durante a obra: a barra do compositor lia as datas cruas direto na

tela. Como ela lê ao vivo, e não do retrato, passou a mostrar a grafia humana **até em relatórios

antigos**, conserto que alcança o passado sem republicar.

Decisão declarada e julgada: a grafia humana entra no retrato a partir de agora. Relatório

publicado antes continua com a forma de máquina até ser republicado. Aceito porque é o **mesmo

padrão** de congelamento que o título e a identidade já usam neste produto. Divergir aqui criaria

uma segunda regra de congelamento. Republicar já é o mecanismo documentado.

O texto enviado à IA mudou junto, de propósito, e o QA conferiu que a composição não degradou.

A LACUNA DE DEPLOY que este cartão revelou, e ela quase entregou o site sem a mudança: a fatia

criou um pacote novo de workspace, e o build do front falhou na main por não achá-lo: o

elo do pacote não existia no checkout de produção. O pnpm install o criou e o build passou. **Só

não virou entrega silenciosa pela metade porque o build é feito antes de publicar**: um fluxo que

publicasse o diretório de saída sem conferir o build teria copiado o pacote anterior, e o site

ficaria no ar sem a mudança, com o merge verde e o cartão fechado. Pacote de workspace novo exige

encadeamento no checkout antes de construir.

Número meu corrigido pelo QA: a redação inicial dizia "oito retratos publicados", e **oito era o

limite da minha consulta**. Medido sem limite: 12 retratos, 9 com período, 2 relatórios publicados.

Achado encaminhado: {F8-40} (o período congela na composição e o título na publicação, dois

momentos diferentes para dois campos vizinhos da mesma abertura).

**Cartão novo, medido em 2026-08-10 antes de mergear o {F8-25}, e ele é o mais estrutural deste

dia. O pacote apps/api do Hub tem 30 arquivos de teste e zero script que execute o

conjunto**: não há test no pacote, não há tarefa equivalente na raiz, não há CI no repositório.

CORREÇÃO IMPORTANTE, e ela foi feita medindo, não relendo: a primeira redação deste cartão dizia

que os arquivos "não rodam por comando nenhum" e que 30 deles falhavam. **As duas coisas estavam

erradas, e o erro nasceu de apontar o executor errado para eles.** Esses arquivos seguem outra

convenção: são programas autônomos, executados um a um, e passam. O arquivo exercitado para

conferir devolveu 7 de 7, incluindo casos adversariais escritos por revisões anteriores. O que não

existe é o comando que roda todos.

Por que o erro merece ficar escrito: um relato de subagent trouxe "30 falharam" e a redação

anterior o adotou. O número era verdadeiro para o executor que ele usou e falso sobre o produto. É

a mesma armadilha que este projeto já nomeou em outro contexto (número que vem pronto também se

mede) e ela é mais perigosa aqui porque o número confirmava a hipótese de quem o recebeu.

O contraste dentro da mesma casa mede o tamanho do buraco: o pacote do módulo

(modularreports-dev) tem cerca de sessenta comandos de teste, incluindo um que roda tudo e outro

que roda a suíte contra banco real. É por isso que todo relato de fatia traz números do módulo

("1408 testes, 143 de integração") e nenhum traz número da API do Hub. Ninguém escondeu nada:

não havia o que contar.

Por que isto invalida promessas já dadas como cumpridas. A guarda entregue pelo {F8-25} promete

que a quarta ocorrência da corrida "não passa em silêncio". Ela mora aqui. Como nada a executa, a

promessa é falsa como entregue, e o mesmo vale para qualquer trava que qualquer fatia anterior

tenha deixado neste pacote. **São duas regras cravadas deste projeto se encontrando no mesmo

ponto:** "nunca falhou" e "nunca rodou" são indistinguíveis, e *guarda que falha aberta em

silêncio não guarda*.

O que implementar: um comando que execute o conjunto na convenção que os arquivos já usam,

agregando os resultados num placar único. **NÃO trocar a convenção de 30 arquivos para acomodar o

comando**: isso é reescrever o corpo de testes inteiro por causa do encanamento, e nenhum deles

pediu para ser reescrito.

A armadilha concreta, e ela quase entrou: um executor de suítes apontado para esses arquivos

reporta 30 falhas que não existem. Um comando test nesse formato é pior que nenhum comando,

porque treina o time a ignorar vermelho, e vermelho ignorado é como uma falha de verdade passa.

**DOIS FATOS MEDIDOS EM 2026-08-10 que quem construir esta fatia vai encontrar, e é melhor saber

antes:**

1. Parte dos arquivos só roda com ambiente e dentro da rede certa. Rodá-los do jeito ingênuo

produz erro de validação de variáveis ausentes, e mesmo com as variáveis carregadas eles falham

ao resolver nomes de container que só existem dentro da rede do Docker. **Isso não é teste podre

nem produto quebrado**: é infraestrutura de execução que nunca foi montada, e é metade do motivo

de não existir comando.

2. E este é o pior: um arquivo imprime "erro fatal" e termina com código de sucesso. Medido:

placar "0 PASS, 0 FAIL, mais erro fatal" e código de saída zero. **Qualquer executor o contaria

como aprovado.** Um comando construído sem tratar isso nasce mentindo: verde por fora, sem ter

executado nada por dentro. Vale conferir quantos arquivos têm esse comportamento antes de confiar

no primeiro placar.

O PLACAR REAL, medido em 2026-08-10 pelo QA do {F8-30}, que rodou os 33 arquivos um a um:

cerca de 67 casos reprovando, concentrados em sete arquivos, **idênticos com e sem a fatia que

ele estava validando**, ou seja, já estavam assim na main. Três outros arquivos nem chegam a

rodar, por ambiente puro (falta de uma ferramenta na imagem de teste, e dois que importam caminhos

de worktree que não existem mais). Um oscila entre execuções, por depender de rede real.

Isto deixa de ser hipótese e vira o argumento do cartão. Ninguém escondeu nada e ninguém foi

desleixado: cada fatia mediu o que tocou e reportou verde honestamente. Como nada executa o

conjunto, as reprovações se acumularam sem dono, e a primeira vez que alguém somou tudo foi por

acaso, comparando placares de outra coisa. Uma delas ({F8-42}) é regressão de uma fatia mergeada

hoje, que nasceu invisível pelo mesmo motivo.

Consequência para o desenho da fatia: o primeiro placar vai vir muito vermelho, e isso é o

produto, não o fracasso. **Separar "reprova por defeito" de "não roda por ambiente" faz parte do

trabalho**: misturar os dois produz um comando que ninguém confia, e comando que ninguém confia é

igual a comando nenhum.

Como verificar (teste primeiro): um único comando executa os 33 arquivos e imprime um placar

que bate com a execução individual; um teste plantado que deve falhar aparece vermelho nesse placar;

o comando reprova quando qualquer arquivo reprova, nunca só o último; **e um arquivo que morre com

erro fatal aparece como reprovado, nunca como aprovado por código de saída zero.**

Aceite (H1): Dado o pacote da API do Hub, Quando alguém roda o comando de teste do projeto,

Então os 33 arquivos são executados e o placar reflete a execução individual de cada um, E um teste

que deve reprovar aparece como reprovado, E nenhum arquivo é pulado em silêncio.

FECHADO em 2026-08-10, mergeado (c601104). QA PASS e review APPROVED. Entrega aditiva: um

script que agrega as execuções individuais, sem trocar a convenção de nenhum arquivo, mais a

documentação de como rodar (incluindo a exigência de ambiente e de estar dentro da rede do Docker,

que é metade do motivo de não existir comando antes).

A prova é ter tentado enganá-lo. O QA plantou três arquivos: um que **imprime reprovação e sai

com código de sucesso (o golpe que existe de verdade no repositório), um mudo**, e um que reprova

honestamente. Os três foram classificados certo: o mudo vira "não rodou", nunca verde. E um arquivo

novo entrou na varredura sem ninguém registrá-lo.

**O PLACAR REAL, medido por três partes com o mesmo número: 35 arquivos, 24 aprovados, 10 reprovando

(73 casos) e 1 que não roda.** O número de arquivos também foi corrigido: eu vinha escrevendo 30 e

depois 33.

O comando se pagou na primeira execução, e o achado é sobre esta sessão: **34 das 73 reprovações,

em 6 arquivos, são a mesma regressão: a trava de título do {F8-26}, que eu mergeei e deployei

hoje, recusando fixtures antigas cujo nome contém número. Eu havia registrado isso como um**

arquivo, porque era o que estava medido quando outro QA tropeçou nele. Enquanto se media arquivo a

arquivo, a regressão parecia caso isolado.

É a demonstração do próprio cartão: não faltou disciplina a ninguém. Cada fatia mediu o que

tocou e reportou verde com honestidade. O que faltava era alguém somar, e ninguém somava porque

não havia comando. Os 6 arquivos restantes agora têm número, lista e assinatura, trabalho seguinte,

com o número na mão.

FECHADO em 2026-10-16, merge Hub d15b8c6 (carimbo 7abf24e; review APPROVED em 4 rodadas, qa PASS

na rodada 2). As 3 guardas em produção: (1) direct-connection-guard no test-all (teste não abre conexão

fora do db.ts); (2) migration 0272 aplicada em produção, CHECK (is_global OR company_id IS NOT NULL)

em reports.template, validada (0 violadores; backup em /root/f8-41-bkp/); (3) `GET

/api/health/dado-de-teste` no ar (200, tudo zero), cadastro como alvo do Vigia em curso. API 15/15.

**Remocao do dado FEITA em 2026-10-15; o cartao segue aberto ate as 3 guardas do plano entrarem

(meta-guarda de Pool nos testes, CHECK em reports.template, sentinela no Vigia).** Apagado em

producao: relatorio 037b52fe (QA temporario do {F8-21}, 10/08, Agencia Teste) com cascata de 1

snapshot e 3 eventos de link (1+1+3), contagens antes/depois conferidas na mesma transacao; as demais

tabelas de reports e hub.accounts/companies iguais. 21 pastas vazias de relatorio removidas do disco

(0 arquivos, 0 pastas restantes). Backup das linhas exatas em /root/f8-41-bkp/ (modo 700/600, sha256).

/api/health 200. Evidencia em /opt/modularhub-evidencias/f8-41/.

Guardas em implementacao (branch feat/f8-41, 2026-10-15): (1) verificador de conexao direta em

teste (scanner que respeita string e regex literal); (2) migration 0272, `CHECK (is_global OR

company_id IS NOT NULL) em reports.template; (3) rota publica GET /health/dado-de-teste` (so

contagens, cache 60 s) para o Vigia. Limite declarado do detector de nome: casa o cartao no inicio

do nome como a suite cria (F8-40, F4-07c, F847, F6-OKR-03, SMK-nn, Cliente Teste/X/Y/Z, prefixo

FIXTURE ); falso positivo aceito: cliente cujo nome comece por F + 3 ou 4 digitos ou por "FIXTURE ";

falso negativo aceito: dado de teste com nome livre, e as empresas descartaveis em si (so as contas e

relatorios delas sao contados). Por isso todo teste novo usa escopoDeFixture / fix.nome.

Cartão novo, medido em 2026-08-10 durante a verificação de resíduo do {F8-39}. Fui conferir se

aquela obra tinha limpado o que criou (tinha) e encontrei o acúmulo de todas as anteriores.

Os números, medidos: 23 relatórios no banco de produção, e todos são fixture de teste. Nenhum

dado de cliente real. Distribuição: 11 rascunhos, 10 revogados e 2 publicados com link vivo; 11

deles têm link que nunca expira. Há títulos explicitamente marcados como temporários, com a

própria instrução de revogar depois do smoke, ainda de pé.

O que torna isto mais que sujeira: cinco relatórios estão sob a conta de uma **agência parceira

real**, não sob a nossa. Quem entrar por lá vê um cliente chamado "Cliente Smoke" na própria lista

de clientes. É o nosso andaime aparecendo na casa de quem confia na plataforma.

A causa não é descuido de uma sessão, é do processo: cada obra declarou "fixtures limpas no fim",

e cada uma estava dizendo a verdade sobre o que ela mesma criou. Ninguém é dono do conjunto. É a

mesma forma de defeito que este projeto já nomeou em código (guarda por ponto de chamada nomeado

deixa o conjunto descoberto), só que aplicada a dados.

O que implementar, e a ordem importa:

1. Inventário nominal dos 23, classificando cada um: descartável, ou algo que alguém ainda usa.

Apagar dado de produção é irreversível e exige aprovação explícita do dono. O inventário é o

que torna essa aprovação possível de dar em um minuto.

2. Revogar antes de apagar os links vivos, que é reversível e tira a exposição imediata.

3. Fechar a torneira: obra de verificação passa a criar fixture sob uma conta reconhecível e

isolada, nunca sob agência parceira, e com expiração curta por construção, não por disciplina de

quem lembra.

Como verificar (teste primeiro): a lista de clientes da agência parceira não mostra nenhuma conta

de teste; e uma obra nova que crie fixture não consegue criá-la fora da conta isolada.

Aceite (H1): Dado o banco de produção, Quando alguém de uma agência parceira abre a lista de

clientes dela, Então nenhuma conta de teste nossa aparece, E nenhum link de teste segue vivo sem

expiração, E fixture nova nasce isolada por construção.

ESCOPO CORRIGIDO no mesmo dia, e o número saltou de 1 para 7. A primeira redação registrava um

arquivo, que era o único conhecido quando o QA do {F8-30} tropeçou nele. Assim que o comando de

teste do {F8-33} rodou o conjunto pela primeira vez, apareceram **mais seis arquivos com a assinatura

exata: número sem origem, apontando o título. Cerca de 34 casos** ao todo.

A lição do salto é a do próprio cartão: o alcance só apareceu quando alguém executou o conjunto.

Enquanto se media arquivo a arquivo, a regressão parecia um caso isolado, e eu a registrei assim,

com confiança, porque era o que estava medido.

Cartão novo, medido em 2026-08-10 pelo QA do {F8-30}, e é uma regressão que ESTA sessão publicou.

O {F8-26} pôs o título dentro da disciplina de número e foi mergeado e deployado hoje. Um arquivo

de teste pré-existente usa um título de fixture que contém um agrupamento de três dígitos, e a trava

nova recusa a publicação por causa dele. Seis testes daquele arquivo caem, em cascata.

O produto está certo; o teste é que ficou inválido. A trava faz exatamente o que foi desenhada

para fazer, e a decisão de recusar código no título está registrada e aceita. O que quebrou foi uma

fixture escrita quando essa regra não existia.

O que torna isto grave não é o defeito, é o modo como escapou. O QA do {F8-26} reportou 40 de

40 verdes. E aquele número não cobria este arquivo. Como nada no projeto executa a suíte da API

por comando ({F8-33}), a reprovação nasceu invisível: só apareceu porque outra fatia, dois cartões

depois, resolveu rodar os 33 arquivos um a um para comparar placares.

É a forma de defeito que este projeto mais paga, agora aplicada a testes: cada gate mediu o que

ele mesmo tocou, ninguém mediu o conjunto, e o placar verde de cada parte somou um todo vermelho.

Cuidado ao consertar: trocar o título da fixture é o conserto óbvio, mas confira antes **o que

aquele arquivo testa**. Se ele publica de propósito com título arbitrário, trocar o texto pode

esconder um segundo problema em vez de resolver o primeiro.

Como verificar (teste primeiro): o arquivo passa por inteiro; e um título com número cru continua

sendo recusado pela trava, provado no mesmo arquivo.

Aceite (H1): Dado o arquivo de teste de identidade, Quando ele é executado, Então todos os casos

passam, E a trava de título continua recusando número sem origem.

PARCIALMENTE FECHADO em 2026-08-10, mergeado (c601104): 1 dos 7 arquivos. O arquivo de

identidade voltou a 40 de 40, e a trava continua recusando número cru, confirmado pelo teste

dedicado dela, intocado: trocar a fixture não afrouxou nada, e o arquivo não testava o texto do

título, só o usava como rótulo.

FECHADO POR INTEIRO em 2026-08-10, mergeado (20e9a4a). Os 6 arquivos restantes entraram numa

segunda fatia, com QA PASS e review APPROVED. A suíte da API foi de 23 para 30 arquivos verdes, e

a assinatura da regressão desapareceu do log: zero ocorrências, medido por três partes.

O risco desta fatia não era o conserto, era ele esconder outra coisa. Trocar o texto do título é

o conserto óbvio, e se em algum arquivo o título importasse para o que estava sendo testado, a troca

teria mascarado o caso. Os dois gates conferiram arquivo a arquivo: o título só entra na criação

do relatório e nunca é lido de volta nem comparado em asserção nenhuma. O diff toca só arquivos

de teste; nenhuma linha de produção, nenhuma verificação afrouxada.

O review foi além e mediu o mecanismo: para o título, o cruzamento contra dados do bloco não

existe, então qualquer dígito reprova, não só código com sigla, como se poderia supor lendo o

cartão. Conferiu que os 32 títulos novos não contêm um único dígito, ou seja, não plantam a próxima

reprovação.

A trava seguiu intocada e exercitada, com o par de casos ao vivo: título limpo publica, título

com número cru recusa apontando o título.

O que sobrou reprovando na suíte não é desta família: quatro arquivos, um sensível ao caminho da

pasta e três de tempo em testes de corrida. Nomeados, para não serem confundidos com esta regressão.

Cartão novo, do achado menor do review do {F8-31} em 2026-08-10. Enquanto aquela fatia tirava a

chamada de IA de dentro da transação, ficou registrado que **o serviço interno que analisa o arquivo

enviado continua dentro dela, e sem limite de tempo declarado**.

É o mesmo defeito com outro nome. O {F8-31} nasceu porque conexão presa durante trabalho longo

esgota o conjunto e para o Hub inteiro, não só o módulo de relatórios. Aquele cartão mirou a IA

porque era o caso medido; a análise de arquivo prende a conexão pela mesma razão, e sem teto pode

prender por tempo indefinido.

Por que ficou de fora, e a decisão foi certa: o {F8-31} tinha caso medido, prova de esgotamento e

desenho pronto para copiar. Misturar teria inchado a fatia e adiado a correção que já estava provada.

Cuidado ao construir: esse serviço roda em processo separado, por desenho de segurança. Ele é o

único com acesso ao motor de contêineres, justamente para a API pública não ter. **Não desfaça esse

isolamento** para resolver o tempo; a saída é a mesma do {F8-31} (ficar fora da transação) mais um

teto próprio.

Como verificar (teste primeiro): com o conjunto de conexões reduzido, uma análise demorada não

bloqueia requisição comum de outro módulo; e uma análise que passe do teto é interrompida com erro

nomeado, sem deixar registro pela metade.

Aceite (H1): Dada uma análise de arquivo demorada em curso, Quando chega uma requisição comum de

outra parte do Hub, Então ela é atendida normalmente, E a análise que ultrapassa o teto é

interrompida com erro nomeado.

FECHADO em 2026-08-10, mergeado (4d9bb08) e deployado. QA PASS e review APPROVED.

O alcance era TRÊS rotas, não uma. O cartão previa só a de criar artefato; a obra mediu e achou

também as duas de importação, que chamam o mesmo serviço. Consertar a nomeada e deixar as duas

teria fechado o cartão com o defeito vivo em dois terços dos casos.

A lição da fatia anterior foi carregada para dentro desta, e funcionou. O {F8-31} perdeu

atomicidade justamente ao aplicar o desenho de duas etapas numa rota cuja primeira etapa escrevia.

A instrução desta fatia trouxe esse alerta, e o review confirmou: nas três rotas a primeira etapa é

leitura pura. O defeito não se repetiu.

O QA testou o que o autor não testou, e é o motivo de o gate existir: forçou falha real de banco

no meio do lote das duas rotas de importação. Resultado: zero linhas sobreviventes (inclusive as

válidas gravadas antes, desfeitas por rollback) e nova tentativa produzindo exatamente três. Nenhum

teste do autor cobria esse caminho.

O número do teto veio de medição, e foi medido duas vezes. O autor: lote de 20 arquivos do

conjunto real, pior caso 1,8 segundo. O QA foi além: gerou 96 MB de arquivos reais, perto do teto da

quota, e mediu 7,8 segundos, ainda cerca de oito vezes de folga sobre os 60 segundos. No caminho

achou um limite por arquivo que não estava documentado.

LIMITE DECLARADO, e ele foi MEDIDO em vez de suposto: o teto fecha a conexão do nosso lado;

não cancela o contêiner que já está trabalhando. Medido com eventos do motor de contêineres: a

nossa ponta desistiu aos 180 milissegundos e o contêiner só terminou aos 792, concluindo

normalmente, sem receber sinal nenhum. Isso não invalida a fatia: o alvo era soltar a conexão do

banco, e isso acontece. Virou {F8-44}, com o conserto no serviço de análise, no outro repositório.

Placar honesto, com divergência reportada em vez de ajustada: o autor mediu 34 aprovados e 5

reprovando; o QA mediu 33 e 6. A diferença é um arquivo com instabilidade de IA real, já documentada,

que oscilou entre as duas rodadas. O conjunto de reprovações é idêntico ao da main: zero falha

nova.

Produção não mudou: a variável do teto não está definida lá, e o padrão é o valor medido.

Cartão novo, escrito em 2026-08-10 a partir de MEDIÇÃO feita durante o {F8-43}, não de suposição.

O que foi medido: com o teto do cliente forçado a 150 milissegundos, a nossa ponta desistiu em

180. O contêiner de análise tinha acabado de arrancar aos 185 e só terminou aos 792: trabalho

normal, concluído com sucesso, nunca interrompido. São cerca de **610 milissegundos de trabalho

remoto depois de ninguém mais estar esperando**, e o número escala com o tamanho do arquivo.

Confirmado no código: o serviço de análise nunca liga a queda da conexão de entrada a um

encerramento do processo que ele disparou.

Por que isto NÃO invalida o {F8-43}: o alvo daquela fatia era soltar a conexão do banco, e

isso acontece de qualquer jeito. O que sobra é desperdício de recurso do lado do serviço, não

travamento do Hub.

Por que ainda assim é dívida: sob carga, cada análise abandonada continua ocupando o serviço de

análise por todo o seu tempo natural. Quem desiste não libera nada lá; e como o serviço é o único

com acesso ao motor de contêineres, é ele o gargalo que sobra.

Onde mora o conserto: no serviço de análise, no outro repositório, fora do alcance da fatia que

o encontrou. Ele precisa observar a queda da conexão de entrada e encerrar o processo que disparou.

Cuidado que não pode ser esquecido: encerrar processo de contêiner é operação privilegiada, e

esse serviço é isolado por desenho justamente por isso. **A correção não pode alargar quem tem esse

acesso**: ela acontece dentro de quem já o tem.

Como verificar (teste primeiro): com o teto do cliente reduzido, o contêiner disparado é

encerrado logo após a desistência, e não segue até o fim natural. O teste precisa falhar hoje.

Aceite (H1): Dada uma análise em curso e um cliente que desiste por tempo, Quando a conexão cai,

Então o processo de análise é encerrado, E nenhum contêiner segue trabalhando sem alguém esperando.

FECHADO em 2026-08-10, mergeado (db1101d) e deployado. QA PASS e review APPROVED.

Este cartão INTRODUZIU um poder destrutivo, e por isso foi o mais escrutinado do dia: encerrar

processos de contêiner, dentro do único serviço com acesso ao motor. As duas perguntas que decidiam

se podia ir ao ar foram respondidas com medição:

1. O alvo pode ser influenciado de fora? Não. O nome vem sempre da própria execução, os três

chamadores de produção nunca o fornecem (só o teste injeta), e não há shell no caminho.

2. Pode matar a análise errada? O QA forçou o caso que a suíte não cobria: **três análises

simultâneas, cancelando duas quase ao mesmo tempo**. Só as duas morreram; a terceira concluiu

intocada. Trocar desperdício por corrupção era o risco real desta fatia.

Prova por eventos do motor de contêineres, com controle negativo: encerramento forçado quando há

cancelamento, término normal quando não há. Nenhum resíduo em disco nem contêiner órfão.

Duas rodadas de ajuste no registro de falha, e a segunda corrige a primeira: o tratamento

original engolia qualquer erro do encerramento, escondendo até uma falha real de acesso ao motor,

e o sintoma visível seria apenas o desperdício voltando, com esta fatia mergeada e verde. Ao

corrigir, porém, o caso benigno (cancelar contêiner que já saiu sozinho) passou a gerar erro em

toda desistência tardia. Detector ruidoso vira catraca: em duas semanas ninguém leria o log, e a

falha real se perderia no ruído. Os dois casos foram separados, com o par provado contra motor real,

inclusive apontando para um destino inalcançável para gerar a falha verdadeira.

Efeito colateral pego pela própria suíte: o auxiliar novo quebrou a verificação de contrato do

barril, que exige todo export público declarado. Classificado como interno.

Nota de processo, declarada: os gates validaram o commit anterior às duas rodadas de log; o delta

posterior é registro de falha, sem alterar a decisão de encerrar nem o desfecho da chamada, com o par

provado e a suíte inteira verde.

Isolamento confirmado no deploy: o acesso ao motor de contêineres segue exclusivo deste serviço.

O leitor e a API continuam sem ele.

**Cartão novo, do achado menor do review do {F8-34} em 2026-08-10, e ele só ficou visível porque as

duas fatias entraram no mesmo dia.**

O desencontro: o título é congelado no ato da publicação ({F8-26}); o período é

congelado no ato da composição ({F8-34}). São dois campos vizinhos na mesma abertura, com dois

momentos de congelamento diferentes.

O que isso produz na prática: entre compor e publicar existe curadoria, e o operador pode

editar. Se ele mudar as datas do relatório depois de compor e publicar sem recompor, a abertura

mostra o período antigo enquanto o resto do documento e o cadastro dizem outro. Ninguém recebe erro:

os dois valores são "certos", cada um do seu momento.

Por que isso é da família mais perigosa deste projeto: é divergência entre camadas em que **as

duas pontas parecem corretas**. Não há teste que reprove, porque nenhum lado está errado

isoladamente, só o par está.

Anterior às duas fatias, e revelado por elas: o congelamento na composição já existia para

outros valores da abertura. O {F8-34} não criou o desencontro, tornou-o visível ao pôr ali um campo

que o operador edita com frequência.

O que implementar: um momento de congelamento só para o que a abertura mostra, ou uma

reconciliação explícita no publish que atualize o que ficou para trás. **Escolher qual é parte da

fatia**, e a escolha precisa olhar o que mais é congelado na composição, não só estes dois campos.

Como verificar (teste primeiro): compor, alterar as datas do relatório, publicar sem recompor, e

conferir que a abertura publicada não contradiz o período do relatório.

Aceite (H1): Dado um relatório composto e depois editado nas datas, Quando o operador publica

sem recompor, Então a abertura publicada não contradiz o período do relatório, E nenhum campo da

abertura mostra valor de um momento diferente dos vizinhos.

FECHADO em 2026-08-10, mergeado (83c0e69 no pacote, 32fcac3 no Hub) e deployado. QA PASS e

review APPROVED, os dois na segunda rodada. Caminho escolhido: reconciliar no publish a partir do

estado atual, seguindo o padrão que o produto já usa para identidade e para o bloco de confiabilidade,

e aplicado também ao preview, para as duas superfícies não poderem divergir.

O achado que REABRE parcialmente uma entrega do mesmo dia, e foi VISTO, não deduzido: o {F8-26}

levou o título ao cliente pela aba do navegador, **mas o texto visível no corpo da abertura continuou

congelado no valor da composição**. O QA publicou um relatório real, renomeou sem recompor, publicou

e olhou: aba com o título novo, corpo com o velho, com captura de tela. **O review havia concluído

o contrário lendo o código**, e eu repassei essa conclusão ao autor, errado nas duas pontas.

Regra de despacho que sai daqui, porque aconteceu duas vezes hoje: quando review e QA divergem

sobre fato observável, quem publicou e olhou tem precedência sobre quem leu o arquivo. O review

aceitou a correção e a registrou no próprio gate.

A regressão que a fatia INTRODUZIU, e ela era sistêmica: ao reconciliar, o título e o período

passaram a ser injetados sempre nas propriedades da abertura, e essas propriedades alimentam a

extração de texto da trava de anti-fadiga. Como título e período sempre diferem entre

relatórios consecutivos do mesmo cliente, a medida de similaridade se diluía e **a trava parava de

disparar. Ou seja: a fatia consertava uma divergência visual e desligava uma trava de honestidade

já em produção**, em silêncio, para todos os relatórios. Achada pelo QA, reproduzida de forma

determinística, invisível ao review.

O conserto foi mais preciso do que a sugestão, e o cuidado merece registro: o período foi para a

lista global de exclusão, porque só existe na abertura; o outro campo NÃO, porque é narrativa

legítima em outros sete tipos de bloco: a exclusão dele foi escopada ao tipo. Uma exclusão

global teria trocado uma regressão por outra maior, enfraquecendo a trava naqueles sete. Os dois

gates confirmaram que não vaza.

O crítico do review, que era o pior desfecho possível: o campo continuava sendo oferecido como

editável. O operador editava, recebia confirmação de sucesso, e a reconciliação **substituía em

silêncio**. Fechado tirando-o dos campos editáveis, recusando a alteração de forma nomeada, e

mostrando-o na tela como informativo com o ponteiro para onde ele de fato muda. A cobertura da

disciplina de número sobrevive pela trava de título, provada por requisição real.

Placar honesto e auditado: o QA mediu 35 aprovados, 5 reprovando, e explicou **as duas que saíram

desde a rodada anterior**: uma por conserto, outra por instabilidade, provada rodando de novo em vez

de embolsar o número melhor.

Cartão novo, do achado do review do {F8-26} em 2026-08-10. O gate de proveniência **já nomeia a

origem de cada número sem dono: o servidor devolve qual bloco (ou o título) causou a recusa. A

tela do compositor não mostra isso**: o operador vê o número cru e a razão, e não sabe onde

procurar.

Por que isto importa mais do que parece: a disciplina de número é a trava que sustenta a página

inteira, e ela bloqueia a publicação. Uma trava que reprova sem dizer onde vira catraca. O

operador que não acha o número aprende a contornar, e é assim que uma guarda boa morre.

A informação já existe e é jogada fora na última camada. Não é preciso construir nada no

servidor: é preciso a tela exibir o que já recebe. Custo baixo, e o defeito é de mostrar, não de

medir.

Anterior ao {F8-26}, e agravado por ele: aquele cartão acrescentou o título como mais uma

origem possível no mesmo balde indiferenciado. Antes o operador tinha que procurar entre os blocos;

agora tem que procurar entre os blocos e o título, com a mesma ausência de pista.

O que implementar: a tela mostra a origem que o servidor já nomeia, junto do número recusado, de

um jeito que leve o operador ao lugar, não apenas o rótulo técnico.

Como verificar (teste primeiro): tentar publicar com número cru no título aponta o título;

com número cru num bloco aponta aquele bloco; e os dois ao mesmo tempo apontam os dois.

Aceite (H1): Dado um relatório recusado na publicação por número sem origem, Quando o operador

vê a recusa, Então ela indica onde está cada número recusado, E o operador chega ao lugar sem

precisar procurar no documento inteiro.

FECHADO em 2026-08-10, mergeado (f91255e) e deployado. QA PASS e review APPROVED. A recusa

passou a dizer o lugar e a levar até ele: o título abre a edição em linha, o bloco abre a edição

daquele bloco, provado com dois blocos do mesmo tipo, para garantir que abre aquele e não o

primeiro. Nada foi construído no servidor: a informação já chegava e era descartada na última

camada.

O defeito que a primeira entrega trouxe, e ele destruía a própria promessa: clicar na violação do

título abria a edição mesmo com o relatório já publicado, e o servidor recusa alterar título

fora de rascunho. O operador clicaria, digitaria e descobriria a recusa ao sair do campo. O caso não

é raro: a mesma rota serve publicar e republicar, então é justamente aí que a recusa aparece com

o relatório publicado. Levar a um campo que não aceita edição é pior que não levar. Corrigido

reusando a mesma condição do botão de renomear, com teste do caso publicado.

Review e QA acharam o mesmo defeito de forma independente, o QA sem conhecer o achado do review.

Redundância entre gates provando que serve para alguma coisa.

Episódio de sessões concorrentes, resolvido sem perda: o QA largou arquivos de rascunho no

worktree compartilhado e quebrou o typecheck da sessão que construía. O construtor removeu o

arquivo, o QA percebeu, limpou e passou a usar cópias descartáveis. Os dois se corrigiram sozinhos.

É o cenário de sessões concorrentes funcionando como deve: **atrito visível em vez de perda

silenciosa**: o arquivo estranho quebrou a compilação em vez de sobrescrever trabalho alheio.

ENTREGUE em 2026-09-21, merge 2dc7730. A saida foi REMOVER, e a medicao e que decidiu.

Gates qa PASS e review APPROVED, os dois viajando dentro do proprio merge.

**O cartao dizia "o texto padrao dela diverge do que esta em producao". Medida, a divergencia e

pior do que isso:** producao (bin/reader-server.mjs:438) usa titulo "Relatorio de resultados"

e descricao vazia; a funcao morta usava "Relatorio" e "Resultados de ${accountName}.".

Liga-la passaria a estampar o nome da conta do cliente no og:description, que e o texto do

preview de link no WhatsApp e no LinkedIn, hoje em branco. Nao era so "muda o que o cliente le":

era expor o nome do cliente em metadado publico. O vazamento nunca chegou a producao, porque

a peca nunca foi acionada; existia so na funcao morta, esperando quem a ligasse.

Recorte que o cartao nao tinha: o arquivo NAO era morto. buildShareCardSvg tem chamador

real (bin/reader-server.mjs) e sanitizeShareCard e usada pelo Hub (routes/reports.ts:4423).

So o resolvedor era inalcancavel, e so ele saiu; as outras duas ficaram intactas, provado por

controle positivo (importar o pacote e conferir que as duas existem e a terceira e undefined).

Ficou escrito no topo do arquivo onde a resolucao real vive e por que duplica-la e perigoso,

para quem for reintroduzir a funcao esbarrar no motivo.

Nao deployado, e nao precisa ser com urgencia: o container do reader roda ha 5 semanas e a

funcao removida era inalcancavel, entao a remocao nao muda comportamento nenhum ate o proximo

deploy do pacote. Isso esta dito para ninguem confundir merge com deploy.

Cartão novo, achado durante a construção do {F8-26} em 2026-08-10. A função que resolve o card de

compartilhamento (src/share-card.mjs) existe, tem testes e nenhum chamador. Pior que inerte:

o texto padrão dela diverge do que está em produção, então quem a ligar acreditando estar

ativando uma peça pronta muda o que o cliente lê, sem perceber.

É a família de defeito mais cara deste projeto, e a contagem já passa de dez ocorrências: peça

construída, testada, aprovada e inalcançável. Ela passa por todos os gates porque cada um olha o

que mudou, e nenhum pergunta "quem, em produção, aciona isto?".

Por que este caso é pior que os anteriores: os outros eram peças inertes. Esta é uma peça inerte

que discorda da realidade. Ligá-la sem comparar os dois textos é trocar o que o cliente vê por

uma versão antiga que ninguém revisou.

O que implementar: decidir entre ligar (e então reconciliar o texto padrão com o que

produção usa hoje, declarando a diferença) ou remover. Não deixar como está: peça pronta e

inalcançável é armadilha para a próxima pessoa.

Conversa com {F8-17}, que varre o CONJUNTO das peças inalcançáveis. Se aquele cartão for feito

antes, este entra nele; se este for feito antes, ele é mais um caso para a varredura provar que

pega.

Como verificar (teste primeiro): ou existe caminho real que a aciona e o texto que o cliente vê

não muda, ou ela não existe mais no código.

Aceite (H1): Dado o resolvedor do card de compartilhamento, Quando o produto roda em produção,

Então ou ele é acionado por um caminho real sem alterar o que o cliente lê, ou ele foi removido, E

não permanece pronto e inalcançável.

FECHADO em 2026-10-16 (pacote a864243 + fix d36a29b, Hub 0bbe7ea; review APPROVED em 2 rodadas,

qa PASS; API 15/15). O orçamento de tempo vive dentro da cadeia: cada provedor recebe min(teto por

provedor ai.fallback.timeout_ms, o que sobra), o último fica com todo o restante, nenhum começa com

menos de 5 s, a chamada cortada é cancelada de verdade; DOCUMENT_TIMEOUT só quando o orçamento cortou

algum elo. O audit da composição grava provider_used, model_used, fallback_depth e latency_ms (a

medida do uso do reserva). Trava contra provedor real estendida ao transporte do pacote em processo de

teste. Os 7 chamadores sem teto não mudam.

**Cartão novo de 2026-08-10, que NASCEU ERRADO e foi corrigido pela medição no mesmo dia. A correção

fica registrada porque a lição vale mais que o cartão.**

A versão errada, e o erro foi meu: escrevi que a composição síncrona, cortada em 50 segundos,

tornava impossível compor um documento real, porque a fórmula de orçamento do produto pede 108 a

150 segundos para 18 a 25 blocos. Tratei a fórmula como se fosse medição. O QA foi medir o tempo

real contra o provedor real: 1,2 a 2,4 segundos, em oito execuções. Folga de vinte a quarenta

vezes. O motivo estava no código o tempo todo: a composição é uma chamada de IA só, não uma por

bloco, então a quantidade de blocos quase não move o relógio.

Achado de lado, e é a família mais cara deste projeto: a fórmula que "escala o teto com o tamanho

do documento" é código morto. O piso dela (60s) é maior que o teto da aplicação (50s), então ela

devolve sempre exatamente o teto, para qualquer quantidade de blocos, provado executando de 1 a

100. A peça existe, é testada, está ligada, e não decide nada.

O que sobra de verdade, e é o motivo de este cartão continuar aberto: quando a cadeia cai no

provedor reserva (cenário real, já ocorrido em produção por esgotamento de cota do principal), o

tempo salta. Medido: 11,7s, 20,7s, 31,4s, **49,85s (cento e quarenta e sete milissegundos de

folga)**, e uma execução acima de 120 segundos. Ou seja, no dia em que o principal falhar, a

composição passa a estourar o teto de forma intermitente, e o operador recebe falha por demora

justamente quando o produto já está degradado.

Não é regressão do {F8-16}: o teto antigo, do proxy, era igualmente apertado, só cortava de

forma desonesta, deixando o trabalho rodando. A fatia trocou o disfarce pela verdade, e a verdade

mostrou que a reserva não cabe no orçamento.

O que implementar, e a escolha é parte da fatia: ou o caminho reserva passa a caber no teto, ou a

composição deixa de depender de uma conexão aberta (e o teto deixa de ser refém do proxy), ou o

produto assume que degradar significa demorar mais e trata isso na tela em vez de falhar. **Meça

antes o quanto a reserva é acionada**: a resposta muda a escolha.

Conversa com {F8-31} (a conexão do banco presa durante a IA): as duas são faces do mesmo desenho

síncrono.

Como verificar (teste primeiro): com o provedor principal indisponível, uma composição de

documento real termina com sucesso de forma repetível, sem depender de sorte no tempo de resposta.

Aceite (H1): Dado o provedor principal indisponível, Quando o operador compõe um relatório de

tamanho real, Então a composição termina com sucesso de forma repetível, E o operador não recebe

falha por demora num momento em que o produto já está degradado.

Cartão novo, escrito em 2026-08-10 a partir do achado I1 do review do {F8-25}, e é anterior

àquela fatia: o review conferiu que o mesmo desenho já estava em main. Fica registrado como

cartão porque recomendação dentro de um gate de review não é fila: o gate fecha, o cartão fica.

O que acontece: em três rotas (criar artefato, e as duas de pesquisa de mercado) a transação e a

conexão do pool são abertas antes da chamada de IA, porque já há escrita e leitura antes dela. A

trava de linha que o {F8-25} acrescentou está no fim e está certa. **O problema não é a trava, é a

conexão**, que fica ocupada durante toda a IA.

Por que isso é caro, e por que não aparece hoje: o pool tem tamanho fixo. Enquanto o produto tem

poucos operadores simultâneos, sobra conexão e nada acontece. Com uma agência de equipe grande, ou

várias agências gerando ao mesmo tempo, as conexões acabam presas esperando IA e **o Hub inteiro

para**, não só o módulo de relatórios, inclusive quem nem está usando relatório. É a classe de

defeito que só se manifesta quando o produto dá certo.

O desenho correto já existe dentro da própria casa: a rota de regeneração de bloco mantém a IA

fora de qualquer transação, em duas transações separadas, e foi apontada pelo review como a mais

segura das quatro. Não é preciso inventar padrão: é preciso as outras três seguirem esta.

O que implementar: as três rotas passam a chamar a IA fora de transação, abrindo a transação de

escrita só depois da resposta, preservando a releitura sob trava que o {F8-25} entregou.

Como verificar (teste primeiro): com o pool reduzido a poucas conexões, várias gerações

simultâneas não esgotam o pool nem bloqueiam uma requisição simples e alheia ao módulo; o teste

falha com o código de hoje.

Aceite (H1): Dado o pool de conexões próximo do limite e várias gerações de IA em curso, Quando

chega uma requisição comum de outra parte do Hub, Então ela é atendida normalmente, E nenhuma

conexão fica ocupada esperando a IA responder.

FECHADO em 2026-08-10, mergeado (51d2b5b) e deployado. QA PASS e review APPROVED, ambos na

segunda rodada.

A prova mais contundente da sessão, e ela mostra que o travamento do Hub era real, não teoria:

com o conjunto de conexões reduzido a duas e duas gerações em curso, uma requisição comum **de outro

módulo do Hub (a listagem de empresas) nunca respondeu** no código antigo: travamento medido,

zero conexão livre. Com o conserto, respondeu em dezenas de milissegundos. Medido dos dois lados,

por duas partes independentes.

A premissa do cartão foi corrigida por medição: ele dizia três rotas. São duas: uma das de

pesquisa de mercado não chama IA nem rede nenhuma, só cura dado já gravado. Confirmado por leitura do

corpo dela pelas duas partes.

O defeito que a fatia INTRODUZIU, e é a lição principal: ao adotar o desenho de duas etapas nas

rotas, a de criar artefato perdeu atomicidade que existia antes: passou a confirmar o registro e

o arquivo em disco antes da IA, deixando órfãos e permitindo duplicação numa nova tentativa. A

causa é sutil e vale escrever: nas outras rotas a primeira etapa só lê; nesta, ela escreve.

Copiar a forma sem olhar essa diferença trocou uma corrida por um vazamento, e tudo continuaria

verde no caminho feliz. É a regra da casa aplicada de novo: toda mudança em código que funciona

declara o que PERDE, não só o que ganha.

A prova do conserto foi feita contra o commit reprovado, pelas duas partes: ele de fato deixa um

registro e um arquivo órfãos; o corrigido não deixa nenhum, falha nomeado, e uma nova tentativa

produz exatamente um artefato.

Terceiro achado, e ele fecha um furo aberto pela própria fatia da manhã: o comando da suíte,

entregue horas antes, conferia o código de saída numa direção só. Reprovação impressa com saída

de sucesso virava reprovação; mas **saída de erro sem linha de reprovação impressa era classificada

como aprovada**. O primeiro arquivo de teste criado depois daquele comando caiu exatamente nesse

furo. A metade simétrica foi acrescentada e a classificação virou peça própria e testável.

O placar caiu de 32 para 31 aprovados, com 6 reprovando, e a queda É o produto. Nenhuma

regressão: um dos dois é o arquivo que agora reprova honestamente em vez de mentir, o outro é

instabilidade de IA real já documentada.

Configuração nova: o tamanho do conjunto de conexões virou ajustável, com piso e documentação, e

produção não mudou: a variável não está definida lá, e o padrão é o valor fixo anterior.

Achado encaminhado: {F8-43}. O serviço de análise de arquivo continua dentro da transação e sem

limite de tempo, pelo mesmo mecanismo, com outro nome.

Cartão novo, do achado I3 do review do {F8-25}, escrito em 2026-08-10. A função que propõe a

leitura dos números altera a estrutura recebida no próprio lugar, por contrato documentado. Por

causa disso, a rota de criar artefato precisou guardar uma cópia da base antes de chamá-la, só para

conseguir calcular o que mudou depois.

O conserto que entrou no {F8-25} trata o sintoma, e isso está declarado. A causa vive no outro

repositório (o pacote do módulo), fora do alcance daquela fatia. Enquanto ela existir, **todo novo

chamador precisa lembrar de tirar a cópia antes**, e quem esquecer não vai receber erro nenhum: vai

receber um delta vazio e concluir que nada mudou.

É a mesma família do que este projeto já chamou de guarda por inclusão nomeada: funciona por

disciplina de quem escreve, não por construção. Some no primeiro chamador distraído.

O que implementar: a função passa a ser pura, devolvendo estrutura nova em vez de alterar a

recebida; os chamadores param de precisar da cópia defensiva, que sai junto.

Como verificar (teste primeiro): chamar a função e conferir que a estrutura passada permanece

idêntica; e um chamador que não faça cópia defensiva ainda assim calcula o delta certo.

Aceite (H1): Dado um chamador que passa uma estrutura de números, Quando a função de leitura é

executada, Então a estrutura original permanece inalterada, E o chamador obtém o resultado sem

precisar de cópia defensiva.

FECHADO em 2026-08-10, mergeado (4610c81 no pacote, f041dee no Hub) e deployado. QA PASS e

review APPROVED, sem nada bloqueante em nenhum dos dois.

A impureza não mudou de dono, ficou contida, que era a pergunta que decidia a fatia. A função

interna continua alterando o que recebe, mas agora o que ela recebe é sempre a cópia local, e o

único outro chamador dela já trabalhava sobre objeto próprio. Os quatro caminhos de retorno devolvem

a cópia; nenhum toca o original.

O detalhe que salvou a cobertura, e quase ninguém teria visto: o apoio de teste também mutava.

Consertar a rota sem consertá-lo teria contaminado o estado "antes" e **escondido a corrida que outro

teste prova**: cobertura falsa, com tudo verde. Foi ajustado junto, com o motivo escrito.

Custo medido contra produção, não estimado: 21 rascunhos reais, média de menos de 3 chaves e

859 bytes, máximo pouco acima de 7 KB. A cópia é irrelevante, e o total de cópias no caminho **caiu

de duas para uma**: a fatia removeu mais trabalho do que acrescentou.

O QA se corrigiu sozinho num falso positivo: a primeira medição dele acusou uma reprovação a mais,

causada pelo nome do próprio worktree que ele criou. Reconheceu como ruído do ambiente e não da

branch, em vez de reportar o número inflado.

Cartão novo, do levantamento pedido no review do {F8-29} em 2026-08-10. Número medido: **6 telas,

7 ocorrências** do mesmo padrão de grid que causou o transbordo daquela fatia: colunas em fração

sem piso declarado, o que faz a trilha ser resolvida pelo conteúdo mais largo.

Hoje é risco latente, não defeito ativo: nenhuma delas tem, no momento, texto com corte reticente,

que é o ingrediente que transforma o padrão em transbordo. **O dia em que alguém acrescentar um, a

tela quebra**, e quem acrescentar não terá como saber.

O agravante, e é o que torna este cartão necessário: existe uma regra global que recorta o

excedente. Ela é legítima e precisa ficar (sustenta o cabeçalho fixo no produto inteiro), mas o

efeito colateral é que transbordo não vira rolagem visível: vira conteúdo cortado e inalcançável.

Foi exatamente por isso que o defeito do {F8-29} viveu escondido, e é por isso que os próximos vão

se esconder do mesmo jeito.

**Ou seja: o produto tem sete lugares onde o defeito pode nascer e um mecanismo que garante que ele

nasça invisível.**

O que implementar, e a segunda metade é a que importa: declarar o piso nas sete ocorrências; e

instrumentar para que o próximo transbordo apareça em vez de ser engolido (por uma verificação que

reprove grid em fração sem piso, ou por um sinal visível em desenvolvimento). Consertar as sete sem isso

deixa o mecanismo de ocultação intacto para a oitava.

Como verificar (teste primeiro): um grid novo com fração sem piso é acusado; e uma tela com texto

de corte reticente numa dessas colunas não transborda em tela estreita.

Aceite (H1): Dada qualquer tela do produto com grid de colunas em fração, Quando conteúdo largo é

colocado nela, Então a página não transborda, E um grid novo sem piso é acusado antes de chegar à

produção.

FECHADO em 2026-08-11, mergeado (be3503d) e deployado. QA PASS e review APPROVED, os dois na

terceira rodada. As sete ocorrências corrigidas sem alterar nenhuma proporção, e uma **varredura por

construção que acusa grid novo sem piso, provada acusando um defeito reintroduzido de verdade**,

em arquivo diferente do que o autor usou, na forma montada dinamicamente.

A guarda nasceu no mesmo buraco que ela existe para fechar, e foi preciso reprovar duas vezes.

Primeira reprovação: a varredura não rodava em comando nenhum. É literalmente o cartão {F8-33},

fechado horas antes: dezenas de testes sem comando que os executasse. Corrigido criando **um comando

na raiz** que agrega o teste do front e a suíte da API, sem reescrever nenhum dos dois.

Segunda reprovação, e ela veio de o review ATACAR a própria solução: o comando distingue "quebrei

agora" de "já estava assim" por um arquivo de referência versionado. O review **acrescentou uma linha

com dado real** e o placar ficou verde: sem revisão, sem motivo obrigatório, sem prazo. A mitigação

era só processo. Corrigido imprimindo sempre quais linhas entraram e saíram na referência, mesmo

em rodada verde, com o ataque simulado e listado.

A trava que fecha o abuso pior foi demonstrada ao vivo, por acidente: rodei o comando num

worktree sem dependências e ele bloqueou, porque sem placar impresso não há o que comparar, sem

exceção de referência nenhuma. Não dá para silenciar suíte que não rodou.

Divergência de medição entre mim e o review, resolvida sem inventar cartão: um arquivo apareceu

como não executado só na rodada dele. Somando as execuções das três partes, ficou **onze verdes

contra uma vermelha**: intermitente, não determinístico, compatível com contenção de recurso num

workspace que roda sessões concorrentes. O autor não acrescentou à referência e não abriu cartão,

porque sem defeito reproduzível não há o que nomear, e acrescentar teria sido exatamente o atalho

que o review acabara de provar que o arquivo permite.

Limites declarados, não descobertos depois: a varredura tem falso negativo quando o valor do grid

vem de variável, e a comparação da referência olha o commit anterior: uma adição enterrada sob

commits seguintes escaparia. Os dois estão escritos.

Achado de ambiente, resolvido no caminho: rodar os testes do front dentro da imagem da API

quebrava por incompatibilidade da imagem, não do código. Cada lado passou a rodar no seu ambiente.

**Cartão novo, medido em 2026-08-10 durante a construção do {F8-27}, e registrado como cartão

próprio porque é anterior e independente daquela obra**, provado assim: um cartão da mesma página

que a obra nunca tocou transborda de forma idêntica.

O que acontece: a ficha do cliente empurra a largura da página para além da tela em celular, e

o corpo do documento passa a rolar na horizontal. É o operador da agência que sofre, não o cliente.

Por que só apareceu agora: este projeto declarou viewport na página pública há poucos dias

({F5-06}); antes disso o navegador de celular desenhava tudo como se fosse tela grande e **todo o

desenho estreito estava adormecido**. Defeito de largura em tela estreita é a classe que aquele

cartão acordou, e é esperado que apareça mais de um.

O que implementar: conteúdo largo rola dentro do próprio recipiente, nunca a página; a regra

vale para o container, não para um seletor pontual, senão o próximo cartão largo reintroduz o

transbordo.

Como verificar (teste primeiro): a ficha de um cliente com nome longo, muitos contatos e metas

preenchidas, aberta em 375px, não rola na horizontal em ponto nenhum da página.

Aceite (H1): Dado um cliente com ficha cheia, Quando o operador a abre em celular, Então a

página não rola horizontalmente, E o conteúdo largo que precisar rolar o faz dentro do próprio

recipiente.

FECHADO em 2026-08-10, mergeado (670ac58) e deployado. QA PASS e review APPROVED. **O diff tem

uma linha de conteúdo; o valor está no diagnóstico.**

A causa é estrutural, e explica por que o sintoma era confuso: o grid principal não declarava

piso para as colunas, então a trilha era resolvida pelo conteúdo mais largo, e texto com corte

reticente tem largura natural igual à frase inteira. O piso foi declarado no container, então

qualquer cartão futuro colocado ali nasce contido.

O que fazia o defeito parecer inexistente: existe uma regra global que recorta o excedente,

herdada de outra correção. Com ela, transbordo **não vira rolagem visível: vira conteúdo cortado e

inalcançável**. Por isso o relato dizia "rola de lado" e a primeira medição bruta dizia "zero

transbordo": as duas estavam certas sobre coisas diferentes.

A regra fica, e a decisão está registrada: ela sustenta o cabeçalho fixo no produto inteiro, e

removê-la teria alcance muito maior que o ganho. Mas **ela é o mecanismo que garante que o próximo

transbordo nasça invisível, daí o {F8-45}, com o número medido: 6 telas, 7 ocorrências** do

mesmo padrão, hoje latentes porque nenhuma tem texto de corte reticente. O dia em que alguém

acrescentar um, quebra sem aviso.

Conserto anterior que veio junto, confirmado como anterior: a proporção entre as colunas em tela

grande já estava errada antes desta fatia, pelo mesmo motivo. Corrigida no mesmo ato, com a proporção

pretendida provada por medição.

O QA resolveu a limitação que travou o autor, em vez de aceitá-la: o ambiente não compunha

imagem, e ele gerou capturas reais usando o próprio motor de renderização do navegador. **Olhou

quatro imagens de verdade**, em duas resoluções, com a ficha cheia, em vez de tratar medição

geométrica como equivalente a ver.

E qualificou a promessa em vez de repeti-la: "nasce contido" vale para o dimensionamento da

coluna; um filho sem corte próprio ainda vaza, invisível por causa da mesma regra de recorte.

Nenhum cartão real da tela tem esse formato hoje: limite declarado, não descoberto depois.

**Cartão novo, escrito em 2026-08-10 depois da TERCEIRA ocorrência da mesma armadilha em dois

dias.** Ele não nasce de um caso: nasce da contagem.

A armadilha, sempre igual: a página declara as variáveis de cor num container, o elemento nasce

fora dele, e a cor simplesmente não alcança. Nada quebra, nada avisa, a suíte fica verde: o

elemento aparece com a cor padrão do navegador, e só quem olha percebe.

As três ocorrências, e o padrão de descoberta é o que mais assusta:

1. {F8-21}, a barra da agência: achada pelo próprio autor no smoke, minutos depois de nascer.

2. {F8-22}, a página de link revogado e expirado: nascida assim desde a Fatia 5, meses no ar

sem cor nenhuma, achada de raspão por quem foi mexer em identidade por outro motivo.

3. {F8-35}, a página de senha: dormente, porque aquela tela ainda não recebe identidade real.

Vai acordar no dia em que passar a receber, e ninguém vai ligar uma coisa à outra.

Ou seja: das três, só uma foi achada por quem a criou. As outras duas dependeram de alguém

passar por perto. Isso não escala, e é exatamente o que a regra da casa chama de exaustivo por

construção contra exaustivo por disciplina.

Por que consertar uma a uma é o caminho errado: as duas primeiras já foram consertadas assim, e

a terceira apareceu mesmo assim. O conserto é de uma linha; o problema é descobrir, e descobrir

é o que nenhum dos consertos anteriores endereçou.

O que implementar: varrer toda página do leitor que declara identidade e conferir, **por

construção**, que a cor declarada alcança o elemento visível. Prefira uma verificação que reprove

no conjunto a uma lista curada de páginas: lista curada faz a página nova nascer furada, que é a

mesma família de defeito por outro eixo. Os consertos de {F8-35} e de qualquer ocorrência que a

varredura achar entram nesta fatia.

Como verificar (teste primeiro): plantar uma página nova com o elemento fora do container e ver

a varredura acusar; e uma com o elemento dentro passar. O primeiro é o que prova.

Aceite (H1): Dada uma página do leitor que declara identidade, Quando a verificação roda, Então

toda página cuja cor declarada não alcança o elemento visível é acusada, E uma página nova com o

mesmo defeito é acusada sem que ninguém precise adicioná-la a uma lista.

FECHADO em 2026-08-10, mergeado (9f7d364) e DEPLOYADO. QA PASS e review APPROVED.

A prova que fecha o cartão é do QA, e é a única que valia: ele plantou um módulo novo com o

elemento fora do container; a varredura o descobriu sozinha e reprovou; ele corrigiu e passou.

Isso é o que separa descoberta por construção de lista curada com outro nome.

A varredura se pagou ANTES de ser aprovada: ela achou uma **quarta ocorrência que ninguém tinha

reportado**: a seção de comentários da página pública, no ar desde 31/07, com texto preto em vez da

cor do tema, medido pelo estilo aplicado num navegador real. Nenhum dos dois consertos pontuais

anteriores a teria encontrado, e ela passou por todos os gates desde então.

Placar final da família: quatro ocorrências, todas corrigidas: duas em fatias anteriores, a

página de senha ({F8-35}) e a seção de comentários, estas duas aqui.

O risco desta fatia era a extração, porque o conserto da seção de comentários mexeu na montagem

da página pública, o caminho mais quente do produto. O review conferiu que a função extraída

reproduz exatamente as inserções anteriores, e que a única mudança é o conserto, não efeito

colateral. Ela é pura, sem acesso a banco, e o teste chama a mesma função de produção em vez de

duplicar a lógica.

Limite declarado, não descoberto depois: a descoberta encontra módulos pela chamada direta à

função de tokens. Um módulo que declare identidade por caminho indireto nasce invisível. Está escrito

no próprio arquivo, e há verificação de sanidade que acusa o mecanismo quebrando por completo.

Detalhes técnicos da entrega. src/identity-scope-guard.mjs

(findUnreachedIdentityConsumers) mede, para qualquer HTML, se toda variável --r-* CONSUMIDA

(em regra CSS, inclusive dentro de @media, ou em style= inline) está de fato aninhada dentro do

elemento que a DECLARA -- por construção, sem jsdom: tokenizador de profundidade de chaves pro CSS

+ parser mínimo de pilha de tags pro HTML, replicando exatamente a cascata de custom property que o

navegador aplica. test/identity-scope-guard.test.mjs prova o par exigido (elemento plantado fora

do container é ACUSADO; o mesmo elemento dentro PASSA), mais 6 casos de borda (@media aninhado,

style= inline, elemento void, classe declarada e nunca usada).

A descoberta É por construção, não lista curada: test/identity-scope-sweep.test.mjs varre

src/*.mjs por grep (quem CHAMA tokensToCssBlock(, nunca quem a define) e exercita toda função

render* exportada por cada arquivo achado, via 2 convenções de chamada genéricas já existentes no

código (objeto único vs document+ctx) -- nenhum nome de página vive no teste. Achou os 3 módulos

reais (render.mjs, reader-invalid-page.mjs, reader-password-page.mjs); um arquivo novo que

chamar tokensToCssBlock( entra sozinho na próxima rodada.

QUARTA ocorrência, achada pela própria varredura e nunca reportada antes (a contagem que o

cartão previu: "melhor ainda: diga quantas achou"): bin/reader-server.mjs colava a seção de

comentários + gate/composer ({F12-03}/{F12-04}/{F12-06}) com .replace("</body>", ...) -- ou seja,

como IRMÃ de <article class="report">, fora do escopo onde --r-* é declarado. Vivo desde

2026-07-31, nunca coberto por teste sem banco (a colagem só existia dentro de

handleReaderRequest, que exige DATABASE_URL). Medido ao vivo com getComputedStyle num

documento reconstruído com as MESMAS funções de produção: .r-comments-title/.r-comment/

.r-comment-gate resolviam color:rgb(0,0,0), nunca a cor do tema. Corrigido extraindo a colagem

como função pura assembleReaderPageHtml (bin/reader-server.mjs, sem banco) e trocando

.replace("</body>", ...) por .replace("</article>", ...) -- test/reader-server-assembly.test.mjs

roda essa função com dados sintéticos e sem DB, com uma regressão nomeada que planta a colagem

ANTIGA e confirma que ela é acusada. Reconfirmado ao vivo contra mhub-db real:

test/reader-server.test.mjs (HTTP real, inclui o bloco {F12} de comentários) 40/40, sem

regressão nas outras 3 fatias que esse arquivo cobre ({F5}, rate-limit, {F13} analytics,

{F8-21}, {F8-08b}).

Placar da varredura, nominal: 4 páginas/pontos de colagem varridos, 4 tinham o defeito antes

desta fatia ({F8-21} e {F8-22} já corrigidos em cartões anteriores; {F8-35}, corrigido junto; a

seção de comentários, achada e corrigida NESTA fatia), 0 ficaram sem conserto. Suíte completa

(npm test) 1470 testes, 0 falhas, 2 skipped (DB-gated, esperado sem DATABASE_URL). Imagem

modularreports-reader builda limpa (reader.Dockerfile, tag de teste f8-36-test, removida

depois).

**Cartão novo, achado ao vivo em 2026-08-10 durante a verificação de {F8-22}, fora do pedido daquele

cartão mas na mesma classe de defeito, a terceira ocorrência dela neste projeto.** tokensToCssBlock

(render-tokens.mjs) escopa as custom properties --r-* ao seletor .report. reader-invalid-page.mjs

tinha o mesmo bug e foi corrigido dentro de {F8-22}; src/reader-password-page.mjs

(renderPasswordGatePage, RF-PUB-003) tem o mesmo desenho e o mesmo defeito, ainda sem conserto:

<main class="r-pwgate"> nunca ganhou a classe report, então a cor resolvida

(resolveAccentColor(branding) || DEFAULT_ACCENT) nunca alcança nenhum elemento da página.

Por que ainda não apareceu em produção: bin/reader-server.mjs sempre chama

renderPasswordGatePage com companyName: null, branding: null -- a tela de senha hoje não recebe

identidade nenhuma, então o sintoma visível seria idêntico com ou sem o bug (a página já mostra o

DEFAULT_ACCENT genérico de qualquer jeito). Isso não torna o cartão dispensável: a função já foi

escrita para receber e aplicar branding real (importa resolveAccentColor, tem a classe

.r-pwgate__agency pronta) -- o dia em que alguém decidir ligar a identidade da agência nessa tela

(mesma decisão que {F8-21} tomou pra revogado/expirado), o defeito reaparece em silêncio, do jeito

mais difícil de notar: código parece certo, cor nunca aplica.

Fora do escopo deste cartão: decidir SE a página de senha deveria mostrar a identidade da agência

hoje (isso é RF-PUB-003 não pedir nem proibir, decisão de produto em aberto) -- este cartão só fecha o

defeito estrutural de escopo CSS, pra quando essa decisão vier o caminho já estar limpo.

RF-PUB-003.

O que implementar: mesmo fix de {F8-22} em reader-invalid-page.mjs -- dar ao <main> a classe

report (<main class="r-pwgate report">), seguro pelo mesmo motivo (documento autocontido, não

importa render-css.mjs/LAYOUT_CSS).

Como verificar (teste primeiro): chamar renderPasswordGatePage com uma cor de teste e confirmar

por getComputedStyle (ou pela mesma prova estrutural de test/reader-invalid-page.test.mjs) que a

cor alcança o elemento, não só a variável declarada no <style>.

NÃO CONSERTAR ISOLADAMENTE: entra junto do {F8-36}, que varre o conjunto. Consertar a terceira

ocorrência uma a uma é o que já se fez com as duas primeiras, e a quarta vai aparecer igual.

Aceite (H1): Dado renderPasswordGatePage chamada com uma identidade resolvida, Quando a página

renderiza, Então a cor resolvida se aplica de fato ao elemento visível, não só é declarada no bloco de

estilo.

FECHADO em 2026-08-10, junto do {F8-36}, mergeado (9f7d364) e DEPLOYADO. O conserto é a **mesma

forma** do da página de link inválido, comparada byte a byte pelo review, não é uma quarta variação

para o mesmo problema. Provado ao vivo com relatório protegido por senha real, medindo o estilo

aplicado em tela grande e celular. <main class="r-pwgate"> virou

<main class="r-pwgate report">. Confirmado por test/identity-scope-sweep.test.mjs

(reader-password-page.mjs, varredura por construção) sem violação.

RF-CMP-007. Publicação bloqueada se qualquer número não tiver dp: (gate HARD, reforça {F1-04}).

Como verificar (teste primeiro): tentar publicar um relatório com um número sem dp: é recusado, apontando exatamente qual número está sem origem.

Aceite (H1): Dado um relatório com ao menos um número sem dp: de origem, Quando o operador tenta publicar, Então a publicação é recusada, E o sistema aponta exatamente quais números estão sem origem.

RF-PUB-002. Token de no mínimo 128 bits, noindex, rate-limit.

Como verificar (teste primeiro): medir o tamanho do token gerado; confirmar header noindex; disparar requisições acima do limite é barrado.

Aceite (H1): Dado um relatório publicado, Quando o link é gerado, Então o token tem no mínimo 128 bits, a página responde com noindex, E requisições acima do rate-limit ao caminho do link são barradas.

RF-PUB-003. Senha de 4 palavras opcional; default sem senha.

Como verificar (teste primeiro): um link com senha pede a senha antes de exibir conteúdo; um link sem senha abre direto.

Aceite (H1): Dado um link com senha definida, Quando alguém abre o link, Então a página pede a senha antes de exibir o conteúdo, E um link sem senha definida abre direto.

RF-PUB-004. Data de expiração opcional; default permanente.

Como verificar (teste primeiro): um link com expiração no passado responde como expirado ({F5-02}); um link sem expiração continua servindo.

Aceite (H1): Dado um link com data de expiração no passado, Quando alguém o abre, Então a página responde como expirada com o estado brandado, E um link sem expiração continua servindo indefinidamente.

RF-PUB-005. Modal de publicação gera QR code do link.

Como verificar (teste primeiro): ler o QR code exibido leva à mesma página do link publicado.

Aceite (H1): Dado um link publicado, Quando o operador abre o modal de publicação, Então um QR code que resolve para o link é exibido e copiável, E ler o QR leva à mesma página do link.

RF-PUB-006, Ap.7. Editar og:title, og:description e capa, com preview de como fica no WhatsApp.

Como verificar (teste primeiro): editar os 3 campos e publicar; compartilhar o link mostra exatamente o card revisado.

Aceite (H1): Dado o modal de publicação, Quando o operador edita og:title, og:description e a capa e publica, Então o link compartilhado exibe exatamente esses metadados no card, E o operador viu o preview do card antes de publicar.

RF-PUB-007. Sistema não envia o link automaticamente; oferece copiar link e QR.

Como verificar (teste primeiro): publicar um relatório não dispara nenhuma mensagem automática ao cliente; o link e o QR ficam disponíveis para copiar.