# Auditoria do Diagnóstico - REL-003 ## Objetivo Validar se o `DIAGNOSTICO_REL_003.md` está corretamente delimitado e se o escopo proposto realmente pertence à `REL-003`, sem alterar código, banco ou documentação existente. ## Documentos Auditados - `docs/relatorios/DIAGNOSTICO_REL_003.md` - `docs/relatorios/ESPECIFICACAO_OFICIAL.md` - `docs/relatorios/MATRIZ_DE_VERDADE.md` - `docs/relatorios/BACKLOG_EXECUTIVO.md` - `docs/relatorios/PLANO_DE_CORRECAO.md` - `docs/relatorios/CASOS_DE_TESTE.md` - `docs/relatorios/PLANO_DE_EXECUCAO.md` - `docs/relatorios/STATUS.md` - `docs/relatorios/DECISOES.md` ## Veredito Executivo O `DIAGNOSTICO_REL_003.md` está **majoritariamente corretamente delimitado** ao escopo da `REL-003`. O núcleo do diagnóstico está aderente ao backlog oficial: - filtros financeiros; - data de corte; - coerência entre KPIs, gráficos e tabela; - coerência de exportações por consequência da mesma base analítica. Foram encontradas apenas duas ressalvas de delimitação: - o arquivo `report-data-table.tsx` foi incluído como potencial impacto, mas **não há evidência suficiente de que ele precise ser alterado** para a implementação mínima da história; - o arquivo `export/route.ts` foi incluído como secundário, porém **não precisa necessariamente ser alterado** se `report.rows` e `report.columns` forem corrigidos na origem. Essas ressalvas **não deslocam a história para fora da REL-003**; apenas refinam melhor o conjunto real de arquivos provavelmente necessários. ## Validação do Escopo Oficial da REL-003 Conforme os documentos oficiais: - `BACKLOG_EXECUTIVO.md` define `REL-003` como `Corrigir filtros, data de corte e tabela analítica financeira`; - `PLANO_DE_EXECUCAO.md` coloca `REL-003` na `Sprint 1`, Marco 1, para congelar a verdade financeira analítica em tela; - os casos oficiais vinculados são `CT-005`, `CT-008`, `CT-009`, `CT-010` e `CT-014`. Portanto, a história está corretamente limitada a: - filtros financeiros; - data de corte; - coerência entre KPIs, gráficos e tabela; - coerência de exportações. ## Classificação dos Itens do Diagnóstico | Item analisado | Classificação | Justificativa | |---|---|---| | Corrigir catálogo de filtros financeiros da aba `Financeiro` | Dentro da REL-003 | Está explicitamente no backlog da história e na especificação da aba financeira | | Corrigir opções de `cliente`, `forma de pagamento` e `status` para o universo financeiro correto | Dentro da REL-003 | Faz parte da correção dos filtros e da semântica oficial do Financeiro | | Adicionar `conta bancária` como filtro oficial da aba financeira | Dentro da REL-003 | Está na especificação funcional da aba `Financeiro` | | Adicionar `categoria financeira` como filtro oficial da aba financeira | Dentro da REL-003 | Está na especificação funcional da aba `Financeiro` | | Adicionar `canal financeiro`, quando aplicável | Dentro da REL-003 | Está na especificação funcional, mas condicionado à existência de fonte confiável | | Corrigir aplicação dos filtros sobre `cash_flow`, `receivable_receipts` e `accounts_receivable` sem misturar universos | Dentro da REL-003 | É a essência da história: filtros corretos e coerência analítica | | Garantir que `paymentMethod` não contamine carteira fora de sua semântica oficial | Dentro da REL-003 | A própria validação da `REL-001` já deixou isso pendente para a `REL-003` | | Aplicar corretamente a data de corte na carteira e no atraso | Dentro da REL-003 | Está explícito no backlog e nos CTs `CT-008` e `CT-009` | | Fazer a tabela financeira reproduzir caixa e carteira de forma auditável | Dentro da REL-003 | Está explícito no backlog: `tabela analítica financeira` | | Fazer exportações refletirem a mesma grade corrigida | Dentro da REL-003 | `CT-014` e especificação exigem paridade tela-exportação | | Revalidar `CT-005`, `CT-008`, `CT-009`, `CT-010` e `CT-014` | Dentro da REL-003 | Casos oficiais vinculados à história | | Exigir trilha oficial entre pedido, pagamento e caixa | Fora da REL-003 | Isso pertence à `REL-004` e à Sprint 2 | | Exigir consistência transacional profunda entre título, recebimento e caixa | Fora da REL-003 | Isso pertence à `REL-005` e à Sprint 2 | | Formalizar estorno e reversão auditável | Fora da REL-003 | Isso pertence à `REL-006` e à Sprint 2 | | Tratar ausência de fonte confiável para `canal financeiro` como bloqueio transacional | Dependência futura | Só vira tema de Sprint 2 se depender de rastreabilidade nova ou modelagem nova | | Conectar `financial_categories` já existente ao módulo de relatórios | Dentro da REL-003 | É correção de filtro e payload de relatório, não de banco | | Alterar banco, migrations, triggers ou procedures | Fora da REL-003 | Proibido pelo histórico da Sprint 1 e deslocado para histórias transacionais futuras | ## Itens que Pertencem à REL-004, REL-005, REL-006 ou Sprint 2 ### REL-004 / Sprint 2 - validação da trilha oficial entre `orders`, `payments` e `cash_flow`; - qualquer necessidade de garantir consistência transacional estrutural entre pedido e caixa; - revisão de triggers, procedures ou geração oficial de eventos financeiros. ### REL-005 / Sprint 2 - validação da trilha oficial entre `accounts_receivable`, `receivable_receipts` e `cash_flow`; - conciliação transacional completa de título x recebimento x caixa; - fechamento estrutural de baixa/reabertura com garantia de rastreabilidade. ### REL-006 / Sprint 2 - formalização de estorno e reversão auditável; - exclusão/reversão com impacto oficial em carteira e caixa; - políticas transacionais de cancelamento com compensação. ### Conclusão sobre invasão de Sprint 2 O `DIAGNOSTICO_REL_003.md` **não invade diretamente** `REL-004`, `REL-005` ou `REL-006`. Ele apenas menciona limitações ou dependências de confiabilidade, o que é aceitável como observação técnica. Não há recomendação de mudança em banco, triggers, procedures ou rotinas transacionais dentro do diagnóstico. ## Confirmação da Limitação Funcional da História ### 1. Filtros financeiros - **Confirmado**: pertence à `REL-003`. - Evidência: `BACKLOG_EXECUTIVO.md` e `ESPECIFICACAO_OFICIAL.md`. ### 2. Data de corte - **Confirmado**: pertence à `REL-003`. - Evidência: backlog da história e CTs `CT-008` e `CT-009`. ### 3. Coerência entre KPIs, gráficos e tabela - **Confirmado**: pertence à `REL-003` no contexto da aba `Financeiro`. - Observação: a história não reabre a semântica dos KPIs nem dos gráficos já aprovados; ela apenas garante que a tabela e os filtros não entrem em contradição com eles. ### 4. Coerência de exportações - **Confirmado**: pertence à `REL-003`. - Justificativa: `CT-014` vincula exportação à mesma verdade da tela e `PLANO_DE_EXECUCAO.md` inclui evidência de tela vs exportação parcial para a `REL-003`. ## Dependências Pendentes da REL-001 ou REL-002 ### REL-001 - **Não há dependência funcional pendente bloqueando a REL-003**. - A `REL-001` já estabilizou os KPIs financeiros. - A pendência documentada em `VALIDACAO_REL_001.md` sobre filtro de `paymentMethod` já foi corretamente empurrada para a `REL-003`. ### REL-002 - **Não há dependência pendente bloqueando a REL-003**. - A `REL-002` e a `REL-002A` já estabilizaram: - gráficos financeiros; - ordenação temporal; - comparação com período anterior; - metadados mínimos de exportação. ### Conclusão - a `REL-003` não depende de reabrir `REL-001` ou `REL-002`; - ela depende apenas de preservar o que já foi estabilizado nelas. ## Arquivos que Realmente Precisam Ser Alterados ### Necessários - `apps/admin/src/lib/reports/service.ts` - necessário para corrigir: - catálogo de filtros financeiros; - aplicação correta dos filtros; - composição da tabela analítica financeira; - coerência entre KPIs, tabela e exportação. - `apps/admin/src/components/reports/report-page-client.tsx` - necessário para expor os filtros oficiais da aba `Financeiro`. ### Provavelmente necessários - `apps/admin/src/lib/reports/contracts.ts` - necessário apenas se o payload de `ReportOptionsPayload` precisar de novos catálogos, como: - `bankAccounts`; - `financialCategories`; - `channels`. ### Condicionais, mas não comprovadamente necessários - `apps/admin/src/components/reports/report-data-table.tsx` - o componente é genérico e já consome `columns` e `rows`; - só precisa ser alterado se a nova tabela exigir tratamento visual novo ou novos tipos de célula. ### Não há evidência de alteração obrigatória - `apps/admin/src/app/api/reports/export/route.ts` - exporta `report.rows` já montado pelo serviço; - se `service.ts` corrigir a origem de `rows` e `columns`, a rota tende a permanecer válida sem modificação. - `apps/admin/src/app/api/reports/route.ts` - é apenas ponto de entrada do relatório; - não há evidência de necessidade de alteração para a `REL-003`. ## Avaliação da Qualidade do DIAGNOSTICO_REL_003.md ### Pontos corretos - delimita corretamente a `REL-003` como história de filtros, data de corte, tabela e exportação coerente; - preserva `REL-001`, `REL-002` e `REL-002A`; - não propõe alteração de banco; - não propõe rastreabilidade transacional de Sprint 2; - identifica corretamente os casos de teste ligados à história. ### Ajustes conceituais recomendáveis - reduzir o peso do `report-data-table.tsx` como arquivo impactado, pois hoje ele parece apenas consumidor genérico do payload; - reduzir o peso de `export/route.ts` como arquivo potencialmente alterado, tratando-o mais como arquivo de validação do que de mudança necessária; - manter `contracts.ts` como arquivo condicional, não obrigatório. ## Recomendação Final O diagnóstico está **suficientemente correto e aderente** para permitir a autorização da `REL-003`, desde que a implementação respeite esta delimitação: - mexer no núcleo financeiro analítico da camada de relatórios; - não invadir rastreabilidade transacional; - não reinterpretar KPIs ou gráficos já aprovados; - priorizar `service.ts` e `report-page-client.tsx`; - tratar `contracts.ts` como condicional; - só tocar `report-data-table.tsx` se ficar comprovadamente necessário. ## Veredito **REL-003 AUTORIZADA** ### Justificativa técnica detalhada - o `DIAGNOSTICO_REL_003.md` está alinhado ao backlog oficial da história e à Sprint 1; - os itens centrais propostos pertencem de fato à `REL-003`: filtros financeiros, data de corte, tabela analítica financeira e coerência de exportação; - não foram identificadas dependências pendentes de `REL-001` ou `REL-002` que impeçam a implementação; - não há invasão material de escopo de `REL-004`, `REL-005`, `REL-006` ou Sprint 2; - a única correção de delimitação necessária é reduzir a percepção de obrigatoriedade sobre arquivos secundários como `report-data-table.tsx` e `export/route.ts`. - portanto, sob critério técnico e documental, a implementação da `REL-003` pode ser autorizada.