# Diagnóstico - REL-006

## Objetivo

Executar exclusivamente a análise arquitetural da `REL-006`, sem implementação, para determinar:

- o estado real do `CT-015`;
- os fluxos atuais de estorno e reversão;
- o relacionamento entre `orders`, `payments`, `accounts_receivable`, `receivable_receipts` e `cash_flow`;
- os pontos que ainda realizam exclusão física;
- os pontos que já usam compensação auditável;
- as lacunas restantes para o modelo imutável definitivo;
- o pacote mínimo de banco, APIs e leitura analítica necessário para aprovação final.

## Base analisada

Documentos:

- `docs/relatorios/DECISAO_CT_015.md`
- `docs/relatorios/DECISAO_ARQUITETURAL_REL_004.md`
- `docs/relatorios/DECISAO_ARQUITETURAL_REL_005.md`
- `docs/relatorios/VALIDACAO_REL_004.md`
- `docs/relatorios/VALIDACAO_REL_005.md`
- `docs/relatorios/CASOS_DE_TESTE.md`
- `docs/relatorios/ESPECIFICACAO_OFICIAL.md`
- `docs/relatorios/MATRIZ_DE_VERDADE.md`

Arquivos de banco e APIs:

- `apps/admin/src/db/migrations/68_add_accounts_receivable_manual.sql`
- `apps/admin/src/db/migrations/69_update_cash_flow_origin_receber.sql`
- `apps/admin/src/db/migrations/71_formalize_payments_cash_flow_pipeline.sql`
- `apps/admin/src/db/migrations/72_replace_delete_payment_cleanup_with_auditable_reversal.sql`
- `apps/admin/src/db/migrations/73_formalize_receivable_receipts_cash_flow_pipeline.sql`
- `apps/admin/src/db/migrations/74_harden_accounts_receivable_lifecycle.sql`
- `apps/admin/src/db/migrations/75_add_minimal_receipt_reversal_support.sql`
- `apps/admin/src/app/actions/financial.ts`
- `apps/admin/src/app/api/pdv/checkout/route.ts`
- `apps/admin/src/app/api/pdv/cancel-sale/route.ts`
- `apps/admin/src/app/api/accounts-receivable/route.ts`
- `apps/admin/src/app/api/accounts-receivable/[id]/receive/route.ts`
- `apps/admin/src/app/api/cash-flow/route.ts`
- `apps/admin/src/lib/reports/service.ts`
- `apps/admin/src/lib/financial-reporting.ts`

## Síntese executiva

O estado atual da Sprint 2 mostra o seguinte:

- a `REL-004` formalizou o trilho `payments -> cash_flow -> orders` e tornou a compensação auditável o comportamento oficial do caixa para o domínio de pagamentos de pedido;
- a `REL-005` formalizou o trilho `accounts_receivable -> receivable_receipts -> cash_flow` e entregou uma reversão mínima do recibo com reabertura do título;
- a `REL-006` continua necessária porque o sistema ainda não atingiu um modelo imutável universal;
- a principal assimetria remanescente é que `receivable_receipts` já possui metadados de reversão, enquanto `payments` ainda termina em exclusão física do evento operacional;
- o `CT-015` ainda não fecha porque o comportamento líquido e auditável está apenas parcialmente padronizado por domínio, não transversalmente;
- a camada analítica atual ainda soma `receivable_receipts` do período como bruto, sem reconciliação líquida universal do recebido após reversão.

## CT-015 completo

## Cenário oficial

Conforme `CASOS_DE_TESTE.md`, o `CT-015` exige:

- recebimento de `R$ 700` já refletido em caixa;
- proibição de exclusão física como política oficial;
- geração de reversão compensatória;
- relatório financeiro com valor líquido correto;
- trilha auditável do evento original e do evento reverso;
- carteira/título reabertos quando aplicável.

## Estado atual do CT-015

Hoje o sistema atende parcialmente esse cenário:

- o domínio `payments` já cria reversão compensatória em `cash_flow`, mas ainda apaga fisicamente a linha de `payments`;
- o domínio `receivable_receipts` já reabre o título sem apagar o recibo, marcando `reversed_at`, `reversed_by` e `reversal_reason`;
- o `cash_flow` já preserva entrada original e saída reversa nos dois domínios;
- a leitura operacional de `cash_flow` já reclassifica `[RECEBER:REVERSAO]` como universo `RECEBER`;
- o relatório financeiro ainda calcula `Valor Recebido` por soma simples de `receivable_receipts.amount` do período, sem liquidar universalmente estornos e reversões.

## Conclusão sobre o CT-015

O `CT-015` permanece pendente porque ainda faltam, em conjunto:

- política universal sem exclusão física do evento financeiro principal;
- vínculo formal e padronizado entre evento original e reverso em todos os domínios;
- leitura analítica líquida coerente entre `receivable_receipts` e `cash_flow`;
- harmonização final entre `payments` e `receivable_receipts`.

## Relação entre as entidades

## 1. `orders -> payments`

Situação atual:

- `payments.order_id` é o vínculo formal com o pedido;
- a migration `71` criou `create_cash_flow_from_payment(...)` e `sync_order_payment_summary(...)`;
- `AFTER INSERT ON payments` cria o `cash_flow` oficial do pagamento;
- `AFTER DELETE ON payments` recalcula `orders.paid_amount` e `orders.financial_status`.

Conclusão:

- o lado `pedido/pagamento` já tem automação persistida;
- a imutabilidade ainda não é plena porque a reversão termina em `DELETE FROM public.payments`.

## 2. `payments -> cash_flow`

Situação atual:

- o fluxo oficial usa `origin = 'PEDIDO'`;
- o vínculo é feito por `cash_flow.reference_id = payment.id`;
- existe proteção de idempotência por índice único parcial;
- a reversão do pagamento gera `cash_flow` de saída com `origin = 'AJUSTE'`.

Conclusão:

- a trilha financeira oficial já existe;
- ainda falta um vínculo universal explícito entre lançamento original e lançamento reverso, além do simples reaproveitamento do `reference_id`.

## 3. `accounts_receivable -> receivable_receipts`

Situação atual:

- `receivable_receipts.receivable_id` vincula cada recebimento ao título;
- `sync_receivable_summary(...)` recalcula `paid_amount` e `status`;
- `guard_accounts_receivable_lifecycle()` protege o ciclo de vida do título;
- `reverse_receipt_with_cash_flow(...)` reabre o saldo do título sem excluir o recibo.

Conclusão:

- o lado `título/recebimento` já tem governança melhor que o lado `payments`;
- ainda falta padronização universal com o mesmo contrato semântico do domínio de pedido.

## 4. `receivable_receipts -> cash_flow`

Situação atual:

- `create_cash_flow_from_receipt(...)` cria `cash_flow` com `origin = 'RECEBER'` e `type = 'IN'`;
- a reversão mínima cria `cash_flow` com `origin = 'AJUSTE'`, `type = 'OUT'` e prefixo `[RECEBER:REVERSAO]`;
- `cash-flow/route.ts` reclassifica semanticamente esse `AJUSTE` para `RECEBER` na leitura operacional.

Conclusão:

- o fluxo já é append-only no caixa;
- a semântica ainda depende de convenção por descrição, não de modelagem universal formal.

## 5. `orders -> accounts_receivable`

Situação atual:

- não existe vínculo formal obrigatório entre `orders` e `accounts_receivable`;
- `accounts_receivable` foi introduzida como carteira financeira oficial sem `order_id`, `source_id` ou `source_type` obrigatórios;
- `REL-005` removeu a carteira híbrida da tela operacional e consolidou `accounts_receivable` como fonte oficial de carteira.

Conclusão:

- `orders` e `accounts_receivable` coexistem como universos financeiros paralelos;
- essa separação foi correta para a Sprint 2 até aqui;
- a `REL-006` não precisa obrigatoriamente fundir os domínios, mas precisa fechar a política universal de reversão entre eles.

## 6. `payments -> receivable_receipts`

Situação atual:

- não existe `payment_id` em `receivable_receipts`;
- não existe correlação formal obrigatória entre pagamento de pedido e baixa de título;
- a harmonização entre os dois universos ainda é indireta, principalmente analítica e conceitual.

Conclusão:

- esse desacoplamento não impediu `REL-004` nem `REL-005`;
- ele permanece como uma limitação importante para leitura transversal e para aprovação integral do `CT-015`.

## Fluxos atuais de estorno

## 1. Estorno manual de pagamento do pedido

Fluxo atual:

1. `apps/admin/src/app/actions/financial.ts` chama `delete_payment_with_cleanup`.
2. A procedure delega para `perform_payment_auditable_cleanup(...)`.
3. A rotina localiza os `cash_flow` originais `PEDIDO`.
4. Para cada lançamento original, cria uma saída `AJUSTE`.
5. Em seguida executa `DELETE FROM public.payments`.
6. A trigger `AFTER DELETE` sincroniza o resumo do pedido.

Propriedade atual:

- usa compensação auditável no caixa;
- ainda usa exclusão física do pagamento.

## 2. Estorno de pagamentos no cancelamento PDV

Fluxo atual:

1. `apps/admin/src/app/api/pdv/cancel-sale/route.ts` busca pagamentos e movimentos do PDV.
2. Remove `cash_flow` vinculados a `pdv_cash_movements` quando existirem.
3. Remove fisicamente `pdv_cash_movements`.
4. Chama `reverse_pdv_order_payments_with_cleanup(...)`.
5. A procedure cria reversões `AJUSTE` para cada `payment`.
6. A procedure exclui fisicamente cada `payment`.
7. A rota cancela o pedido e grava `order_history`.

Propriedade atual:

- o estorno financeiro oficial de `payments` já é compensatório;
- o cancelamento PDV ainda contém exclusões físicas operacionais e até remoção de `cash_flow` associado a movimento operacional.

## 3. Estorno de recebimento do título

Fluxo atual:

1. `apps/admin/src/app/api/accounts-receivable/route.ts` recebe `action = "reverse_receipt"`.
2. A rota chama `reverse_receipt_with_cash_flow(...)`.
3. A routine marca `reversed_at`, `reversed_by`, `reversal_reason` e `reversed_receipt_id`.
4. Gera uma saída `AJUSTE` em `cash_flow` com prefixo `[RECEBER:REVERSAO]`.
5. Executa `sync_receivable_summary(...)`.
6. O título volta para `PENDING`, `PARTIALLY_PAID` ou `OVERDUE`, conforme saldo e vencimento.

Propriedade atual:

- não apaga o recibo;
- já é aderente ao modelo imutável dentro do próprio domínio;
- ainda não estabelece um contrato universal replicado em `payments`.

## Fluxos atuais de reversão

## Reversão já formalizada

- `payments`: reversão compensatória em `cash_flow`, seguida de exclusão física do `payment`;
- `receivable_receipts`: reversão por marcação do próprio evento, com reabertura do título e compensação em `cash_flow`;
- `cash_flow`: mantém entrada original e saída reversa;
- `orders`: resumo financeiro recalculado após inserção e exclusão de `payments`;
- `accounts_receivable`: resumo financeiro recalculado após inserção, atualização, exclusão e reversão lógica de `receivable_receipts`.

## Reversão ainda não universalizada

- não existe uma política única e homogênea entre `payments` e `receivable_receipts`;
- `payments` não possui `reversed_at`, `reversed_by` ou `reversal_reason`;
- o vínculo original/reverso em `cash_flow` ainda é inferido mais por `reference_id`, `origin` e `description` do que por um modelo universal de pareamento;
- a camada analítica não trata o líquido de forma uniforme entre os dois domínios.

## Eventos que ainda realizam exclusão física

## Exclusão física ainda presente

- `perform_payment_auditable_cleanup(...)` executa `DELETE FROM public.payments`;
- `reverse_pdv_order_payments_with_cleanup(...)` herda o mesmo comportamento por pagamento;
- `apps/admin/src/app/api/pdv/cancel-sale/route.ts` executa `.delete()` em `pdv_cash_movements`;
- `apps/admin/src/app/api/pdv/cancel-sale/route.ts` executa `.delete()` em `cash_flow` vinculado a `pdv_cash_movements`;
- a modelagem-base de `receivable_receipts.receivable_id REFERENCES accounts_receivable(id) ON DELETE CASCADE` ainda deixa aberta a possibilidade estrutural de eliminação física em cascata, mesmo sem rota oficial atual.

## Interpretação arquitetural

Hoje a regra "exclusão física não permitida" ainda não está plenamente consolidada porque:

- ela já é respeitada no domínio de recibos;
- ela ainda não é respeitada no domínio de pagamentos;
- ela ainda não é endurecida por guarda persistida contra `DELETE` em tabelas financeiras-chave.

## Eventos que já utilizam compensação auditável

- inserção de `payments` gera `cash_flow PEDIDO` oficial;
- exclusão operacional de pagamento gera saída `AJUSTE` antes da remoção do `payment`;
- cancelamento PDV reutiliza a mesma policy oficial de reversão de pagamento;
- inserção de `receivable_receipts` gera `cash_flow RECEBER` oficial;
- reversão mínima de recibo gera saída `AJUSTE` com rastro semântico de reversão;
- `cash-flow/route.ts` já reconhece reversões mínimas de recebíveis como universo `RECEBER` na leitura.

## Procedures e triggers existentes criadas nas REL-004 e REL-005

## REL-004

### Procedures e functions

- `resolve_payment_company_id(p_payment_id uuid)`
- `sync_order_payment_summary(p_order_id uuid)`
- `create_cash_flow_from_payment(p_payment_id uuid)`
- `perform_payment_auditable_cleanup(p_payment_id uuid, p_order_id uuid, p_allow_pdv boolean, p_reason text)`
- `delete_payment_with_cleanup(p_payment_id uuid, p_order_id uuid)`
- `reverse_pdv_order_payments_with_cleanup(p_order_id uuid)`

### Triggers

- `payments_financial_effects_after_insert`
- `payments_financial_effects_after_delete`

### Trigger functions

- `handle_payment_financial_after_insert()`
- `handle_payment_financial_after_delete()`

## REL-005

### Procedures e functions

- `resolve_receivable_company_id(p_receivable_id uuid)`
- `sync_receivable_summary(p_receivable_id uuid)`
- `create_cash_flow_from_receipt(p_receipt_id uuid)`
- `register_receipt_with_cash_flow(...)`
- `sync_accounts_receivable_status()`
- `guard_accounts_receivable_lifecycle()`
- `reverse_receipt_with_cash_flow(p_receipt_id uuid, p_reason text)`

### Triggers

- `receivable_receipts_financial_after_insert`
- `trg_accounts_receivable_guard_lifecycle`
- `trg_sync_accounts_receivable_status`

### Trigger functions

- `handle_receipt_financial_after_insert()`

## Dependências entre banco e APIs

## 1. Inserção de pagamento

Dependência:

- `apps/admin/src/app/actions/financial.ts`
- `apps/admin/src/app/api/pdv/checkout/route.ts`
- trigger `payments_financial_effects_after_insert`
- functions `create_cash_flow_from_payment(...)` e `sync_order_payment_summary(...)`

Leitura:

- a aplicação só insere em `payments`;
- o banco materializa `cash_flow` e sincroniza `orders`.

## 2. Estorno de pagamento

Dependência:

- `apps/admin/src/app/actions/financial.ts`
- `apps/admin/src/app/api/pdv/cancel-sale/route.ts`
- procedure `delete_payment_with_cleanup(...)`
- procedure `reverse_pdv_order_payments_with_cleanup(...)`

Leitura:

- a API já depende da política persistida;
- a limitação ainda está no desenho da própria routine, que compensa e depois apaga.

## 3. Inserção de recebimento

Dependência:

- `apps/admin/src/app/api/accounts-receivable/[id]/receive/route.ts`
- procedure `register_receipt_with_cash_flow(...)`
- trigger `receivable_receipts_financial_after_insert`
- functions `create_cash_flow_from_receipt(...)` e `sync_receivable_summary(...)`

Leitura:

- a rota já deixou de orquestrar manualmente recibo, título e caixa;
- o banco já é a fonte oficial da transação.

## 4. Reversão de recebimento

Dependência:

- `apps/admin/src/app/api/accounts-receivable/route.ts`
- procedure `reverse_receipt_with_cash_flow(...)`
- trigger `trg_sync_accounts_receivable_status`
- function `sync_receivable_summary(...)`

Leitura:

- a API já usa uma routine oficial;
- a política ainda é local ao domínio `receivable_receipts`.

## 5. Leitura do fluxo de caixa e dos relatórios

Dependência:

- `apps/admin/src/app/api/cash-flow/route.ts`
- `apps/admin/src/lib/reports/service.ts`
- `apps/admin/src/lib/financial-reporting.ts`

Leitura:

- `cash-flow/route.ts` já enriquece semanticamente reversões de `RECEBER`;
- `service.ts` ainda soma `receivable_receipts` do período como bruto;
- `financial-reporting.ts` ainda lê `cash_flow` por origem, mas não fecha um contrato líquido universal para `CT-015`.

## Lacunas para atingir o modelo imutável definitivo

## 1. Assimetria entre `payments` e `receivable_receipts`

- `receivable_receipts` já é reversível sem delete;
- `payments` ainda é compensado e depois excluído.

## 2. Falta de metadados de reversão em `payments`

- não há `reversed_at`;
- não há `reversed_by`;
- não há `reversal_reason`;
- não há vínculo explícito do pagamento revertido com seu estado reverso.

## 3. Falta de vínculo universal original/reverso

- o pareamento atual depende de `reference_id`, `origin` e convenções de `description`;
- isso funciona por domínio, mas ainda não é um contrato universal do sistema.

## 4. PDV ainda não está em modelo append-only

- `pdv_cash_movements` ainda pode ser removido;
- a própria rota apaga `cash_flow` vinculado a movimentos operacionais do PDV.

## 5. Leitura analítica ainda não fecha o líquido do recebido

- `service.ts` consulta `receivable_receipts` do período sem excluir explicitamente recibos revertidos;
- `totalReceived` ainda é calculado por soma simples dos recibos do período;
- o fluxo líquido existe em `cash_flow`, mas o KPI de `Valor Recebido` não aplica reconciliação transversal equivalente.

## 6. Falta de guarda contra deleções físicas em tabelas financeiras

- não há bloqueio persistido universal para `DELETE` em `payments`;
- não há bloqueio persistido universal para `DELETE` em `cash_flow`;
- não há endurecimento equivalente para prevenir trilhas parciais no PDV.

## 7. Relação cross-domain ainda implícita

- `orders` e `accounts_receivable` não possuem vínculo formal obrigatório;
- `payments` e `receivable_receipts` não possuem vínculo formal obrigatório;
- a consolidação do `CT-015` ainda depende de reconciliação entre universos paralelos.

## Arquivos obrigatórios para REL-006

- `apps/admin/src/app/actions/financial.ts`
- `apps/admin/src/app/api/pdv/cancel-sale/route.ts`
- `apps/admin/src/app/api/accounts-receivable/route.ts`
- `apps/admin/src/app/api/cash-flow/route.ts`
- `apps/admin/src/lib/reports/service.ts`
- novas migrations em `apps/admin/src/db/migrations/`

## Arquivos prováveis

- `apps/admin/src/lib/financial-reporting.ts`
- `apps/admin/src/components/orders/financial-section.tsx`
- `apps/admin/src/app/dashboard/financial/receivables/page.tsx`
- `apps/admin/src/app/dashboard/financial/cash-flow/page.tsx`

## Arquivos condicionais

- `apps/admin/src/components/reports/report-page-client.tsx`
- `apps/admin/src/components/reports/report-charts.tsx`
- `apps/admin/src/lib/reports/contracts.ts`
- `apps/admin/src/app/api/accounts-receivable/[id]/receive/route.ts`
- endpoint dedicado para reversão financeira universal, caso a equipe não concentre tudo nas rotas já existentes

## Arquivos que não devem ser alterados

- `docs/relatorios/STATUS.md`
- `docs/relatorios/CHANGELOG.md`
- `docs/relatorios/DECISOES.md`
- documentos históricos de validação e decisão das `REL-004` e `REL-005`
- `apps/admin/src/db/migrations/68_add_accounts_receivable_manual.sql`
- `apps/admin/src/db/migrations/69_update_cash_flow_origin_receber.sql`
- `apps/admin/src/db/migrations/71_formalize_payments_cash_flow_pipeline.sql`
- `apps/admin/src/db/migrations/72_replace_delete_payment_cleanup_with_auditable_reversal.sql`
- `apps/admin/src/db/migrations/73_formalize_receivable_receipts_cash_flow_pipeline.sql`
- `apps/admin/src/db/migrations/74_harden_accounts_receivable_lifecycle.sql`
- `apps/admin/src/db/migrations/75_add_minimal_receipt_reversal_support.sql`
- `apps/admin/src/app/api/pdv/checkout/route.ts`
- a camada analítica da Sprint 1 fora do recorte financeiro de `CT-015`

## Migrations necessárias

## Migration 1 - Obrigatória

### Nome sugerido

- `76_add_payment_reversal_metadata_and_block_physical_delete.sql`

### Conteúdo mínimo

- adicionar metadados de reversão em `payments`;
- substituir a semântica de exclusão por semântica de reversão lógica;
- bloquear deleção física direta do evento financeiro principal;
- preparar sincronização de `orders` por reversão lógica, não por `DELETE`.

## Migration 2 - Obrigatória

### Nome sugerido

- `77_finalize_universal_financial_reversal_contract.sql`

### Conteúdo mínimo

- padronizar o vínculo entre evento original e evento reverso;
- endurecer a política universal para `cash_flow`;
- permitir leitura inequívoca de reversão sem depender de prefixo textual;
- consolidar o contrato comum entre `payments` e `receivable_receipts`.

## Migration 3 - Provável

### Nome sugerido

- `78_harden_pdv_operational_audit_trail.sql`

### Conteúdo mínimo

- remover exclusões físicas de `pdv_cash_movements` como fluxo principal;
- impedir remoção indevida de `cash_flow` associado ao cancelamento PDV;
- registrar compensações operacionais em vez de eliminação.

## Procedures necessárias

## Obrigatórias

- `reverse_payment_with_cash_flow(p_payment_id uuid, p_reason text DEFAULT NULL)`
  - deve substituir a exclusão física do pagamento por reversão lógica auditável

- `reverse_receipt_with_cash_flow(p_receipt_id uuid, p_reason text DEFAULT NULL)`
  - deve ser mantida, mas harmonizada ao contrato universal da `REL-006`

- helper persistido para pareamento universal entre evento original e reverso
  - pode ser uma routine dedicada ou absorvido pelas procedures de reversão

## Prováveis

- reescrita ou substituição de `reverse_pdv_order_payments_with_cleanup(p_order_id uuid)`
  - para deixar de depender de cleanup físico

- helper para reversão operacional do PDV
  - se a equipe optar por tornar `pdv_cash_movements` append-only

## Não necessárias como alvo principal

- procedures de criação de pagamento;
- procedures de criação de recibo;
- alterações em rotas comerciais de venda fora do cancelamento e do estorno.

## Triggers necessárias

## Obrigatórias

- trigger de guarda `BEFORE DELETE ON public.payments`
  - deve impedir exclusão física comum do evento

- trigger/routine orientada a reversão lógica em `payments`
  - deve sincronizar `orders` quando o pagamento for revertido sem delete

- trigger de guarda `BEFORE DELETE ON public.cash_flow`
  - deve proteger lançamentos financeiros oficiais contra remoção indevida

## Prováveis

- trigger de guarda `BEFORE DELETE ON public.receivable_receipts`
  - para consolidar o princípio universal de não exclusão física

- trigger de guarda em `pdv_cash_movements`
  - se o escopo final da `REL-006` absorver também o endurecimento operacional do PDV

## Não obrigatórias para o pacote mínimo

- triggers em `orders` fora da sincronização financeira;
- triggers na camada analítica;
- alterações em tabelas comerciais que não participam do estorno auditável.

## Estratégia para aprovação definitiva do CT-015

1. Eliminar a exclusão física de `payments` como fluxo oficial.
2. Preservar a reversão mínima de `receivable_receipts`, mas alinhá-la ao mesmo contrato universal de reversão.
3. Padronizar o vínculo entre evento original e reverso em `cash_flow` e nos eventos operacionais de origem.
4. Remover da rota `pdv/cancel-sale` qualquer deleção física de trilha financeira oficial.
5. Ajustar `cash-flow/route.ts` para usar metadados estruturais de reversão, e não apenas convenção textual.
6. Ajustar `service.ts` para calcular `Valor Recebido` na visão líquida oficial quando houver reversão formal.
7. Reexecutar o `CT-015` com evidência cruzada entre:
   - evento original;
   - evento reverso;
   - reabertura do título quando aplicável;
   - `Fluxo de Caixa Líquido`;
   - `Valor Recebido` líquido;
   - tabela financeira e exportação.

## Conclusão diagnóstica

O diagnóstico mostra que a `REL-006` não precisa mais descobrir o problema estrutural do projeto. Esse problema já está suficientemente isolado:

- a `REL-004` fechou o lado `orders/payments/cash_flow`;
- a `REL-005` fechou o lado `accounts_receivable/receivable_receipts/cash_flow`;
- o que resta agora é padronizar a política universal de reversão e imutabilidade;
- o `CT-015` continua pendente por uma lacuna objetiva e bem delimitada, não por incerteza de escopo.

Portanto, do ponto de vista arquitetural, o pacote da `REL-006` já está claro, delimitado e executável sem reabrir indevidamente as histórias anteriores.

- **REL-006 AUTORIZADA**