Painel de leitura da documentação, planejamento e implementação por feature, com seleção centralizada antes da navegação.
stepsCompleted:
This document provides the complete epic and story breakdown for cobranca, decomposing the requirements from the PRD, UX Design if it exists, and Architecture requirements into implementable stories.
FR1: Cobradores podem visualizar no dashboard_cobrador.php os titulos da Chronos que pertencem aos clientes de sua carteira operacional.
FR2: O sistema pode consolidar dados das fontes atuais e da Chronos em uma mesma visao funcional do dashboard.
FR3: O sistema pode tratar a Chronos como fonte complementar, sem remover da visao os titulos atualmente exibidos pela logica Bralar.
FR4: O sistema pode identificar a origem de cada titulo exibido como Travessia ou Bralar.
FR5: O sistema pode exibir todos os titulos elegiveis do cliente no grid correspondente, sem colapsar titulos distintos do mesmo cpf_cnpj.
FR6: O sistema pode classificar titulos da Chronos em quebras quando estiverem em aberto e vencidos segundo a regra funcional validada.
FR7: O sistema pode classificar titulos pagos da Chronos em 30 dias quando houver marcacao operacional correspondente no banco auxiliar.
FR8: O sistema pode classificar titulos pagos da Chronos em renegociacoes quando atenderem ao criterio funcional validado para renegociacao.
FR9: O sistema pode garantir que um mesmo titulo Chronos apareca em apenas um grid funcional por vez.
FR10: O sistema pode aplicar a mesma classificacao de forma deterministica sempre que o mesmo titulo for consultado no mesmo contexto de dados.
FR11: Analistas podem entender em qual categoria um titulo foi enquadrado e qual regra funcional sustentou esse enquadramento.
FR12: Cobradores podem visualizar titulos Travessia elegiveis no grid de quebras junto com os titulos ja existentes.
FR13: O sistema pode apresentar no grid de quebras as informacoes operacionais necessarias para o tratamento do titulo, incluindo cliente, documento, proposta, residencial, valor e vencimento.
FR14: O sistema pode manter o comportamento atual de filtragem por carteira do cobrador ao incluir os titulos Travessia no grid de quebras.
FR15: O sistema pode preservar a leitura operacional do grid de quebras sem exigir fluxo paralelo ou consulta externa para completar a visao do cliente.
FR16: O sistema pode manter funcionais, para linhas Bralar e Travessia em quebras, os botões de ação de Histórico do cliente e Triagem Jurídica.
FR17: O botão Histórico do cliente deve continuar abrindo a visão consolidada do CPF, preservando históricos MySQL e exibindo fallback de dados da Chronos quando o SQL Server não tiver contexto suficiente para clientes Travessia.
FR18: O botão Triagem Jurídica deve continuar enviando CPF, contrato e contexto operacional corretos para o fluxo jurídico também para títulos Travessia, sem depender implicitamente de formato de proposta exclusivo da Bralar.
FR46: Quando a API Chronos não fornecer todos os campos operacionais necessários ao dashboard, o sistema pode enriquecer registros Travessia consultando o SQL Server por cpf_cnpj e referências operacionais derivadas, sem perder a identidade original do título Chronos.
FR19: Cobradores podem registrar titulos elegiveis da Travessia no fluxo de 30 dias usando o mesmo processo operacional ja existente.
FR20: O sistema pode persistir a marcacao de 30 dias para clientes/titulos Travessia no banco auxiliar usado pela operacao atual.
FR21: Cobradores podem visualizar no grid de 30 dias os titulos pagos da Travessia que tenham sido corretamente vinculados a esse fluxo.
FR22: O sistema pode usar a marcacao operacional existente como fonte de verdade para a elegibilidade de 30 dias, independentemente da origem do titulo.
FR23: Gerencia pode incluir os titulos Travessia marcados em 30 dias nos indicadores e totais relacionados a esse fluxo.
FR24: Cobradores podem visualizar no grid de renegociacoes os titulos pagos da Travessia que se enquadrem na regra funcional de renegociacao.
FR25: O sistema pode manter separado o fluxo de renegociacoes do fluxo de 30 dias, evitando dupla contagem e ambiguidade operacional.
FR26: O sistema pode exibir os titulos renegociados da Travessia com o mesmo nivel de contexto operacional usado para os titulos atuais da Bralar.
FR47: Cobradores podem visualizar no grid de advogado os titulos pagos da Travessia cujo enriquecimento no SQL Server indique NumeroContratoBanco LIKE '%adv%'.
FR48: O sistema pode usar o SQL Server como fonte de enriquecimento para decidir se um titulo pago da Travessia pertence a advogado ou a renegociacoes, preservando a identidade original do titulo Chronos.
FR49: O sistema deve aplicar precedencia funcional entre grids pagos para evitar duplicidade, obedecendo no minimo a ordem 30 dias > advogado > renegociacoes.
FR27: O sistema pode incorporar os titulos Travessia aos indicadores do dashboard quando eles fizerem parte do fluxo funcional correspondente.
FR28: Gerencia pode consultar indicadores consolidados sem perder coerencia entre valores agregados e linhas exibidas nos grids homologados.
FR29: O sistema pode manter separados os titulos que ainda nao pertencem a nenhuma categoria funcional suportada no MVP, sem inflar indicadores indevidamente.
FR30: O sistema pode preservar os comportamentos atuais dos indicadores que dependem do banco auxiliar, adicionando a Travessia apenas quando houver base funcional validada para isso.
FR31: Cobradores podem continuar usando os filtros atuais do dashboard, incluindo periodo e busca, sobre a visao consolidada, sem mudanca de UX.
FR32: O sistema pode aplicar os filtros e buscas existentes de maneira equivalente aos titulos da Bralar e da Travessia sempre que houver semantica funcional correspondente.
FR33: O sistema pode executar a busca consolidada sobre as tres fontes envolvidas na visao do dashboard, considerando SQL Server, MySQL e Chronos quando necessario para o grid consultado.
FR34: O sistema pode normalizar os campos de busca equivalentes entre as tres fontes, incluindo nome do cliente, cpf_cnpj, proposta e referencias operacionais compatíveis, para devolver resultado coerente ao usuario.
FR35: O sistema pode validar, antes de incluir qualquer titulo Chronos em um grid operacional do cobrador, se o cpf_cnpj do cliente pertence ao usuario logado segundo cobranca_atribuicao_cliente com status = 'ATIVO'.
FR36: O sistema pode usar cobranca_atribuicao_cliente como fonte unica de ownership da carteira tambem para os titulos Travessia, sem depender de nome de cobrador ou qualquer sinalizacao externa da Chronos.
FR37: Usuarios podem identificar visualmente a origem Travessia/Bralar de cada registro sem perder a legibilidade do dashboard.
FR38: O sistema pode continuar disponibilizando a operacao atual mesmo quando a Chronos estiver temporariamente indisponivel.
FR39: O sistema pode omitir temporariamente os dados da Chronos em caso de falha da integracao, sem quebrar sessao, dashboard ou grids existentes.
FR40: O sistema pode registrar eventos de erro e inconsistencias da integracao de forma que a equipe consiga diagnosticar problemas sem depender de observacao informal do usuario.
FR41: Analistas e equipe tecnica podem rastrear a origem funcional de cada titulo consolidado usado na homologacao.
FR42: O sistema pode distinguir, para fins de analise, se um titulo foi exibido por regra da fonte atual ou por regra da Chronos.
FR43: O sistema pode ser ativado e validado em cobranca-hml antes de qualquer liberacao para producao.
FR44: O sistema pode permitir rollout controlado da integracao Chronos sem exigir mudanca imediata de todos os fluxos relacionados fora do MVP.
FR45: O sistema pode incorporar os titulos Chronos elegiveis no fluxo advogado sem contaminar 30 dias ou renegociacoes.
NFR1: As consultas do dashboard impactadas pela feature devem manter tempo de resposta percebido compativel com uso operacional diario, sem degradacao que inviabilize o trabalho normal do cobrador.
NFR2: A integracao Chronos deve evitar chamadas redundantes para os mesmos dados dentro de um mesmo fluxo de uso, especialmente quando filtros, buscas e periodos consultados nao mudarem.
NFR3: O carregamento adicional da fonte Chronos deve ser limitado ao subconjunto de carteira e periodo realmente necessario para a operacao do usuario logado.
NFR4: O sistema deve permitir instrumentacao de tempo de consulta e volume retornado pela Chronos durante homologacao, para identificar gargalos antes da publicacao.
NFR5: Credenciais da Chronos devem permanecer fora do codigo versionado e fora de qualquer resposta enviada ao navegador.
NFR6: O consumo da Chronos deve ocorrer apenas no backend autenticado do sistema, sem expor token OAuth2 ao frontend.
NFR7: Logs e mensagens de erro nao devem expor client_secret, token de acesso ou payloads sensiveis completos desnecessariamente.
NFR8: A feature deve manter o mesmo nivel atual de controle de acesso do sistema para endpoints, dashboard e indicadores, sem ampliar visibilidade de dados para perfis nao autorizados.
NFR9: Dados pessoais e financeiros usados na consolidacao devem ser tratados com minimizacao de exposicao compatível com a operacao interna do sistema.
NFR10: A indisponibilidade da Chronos nao pode derrubar o dashboard nem inutilizar os fluxos atuais baseados em SQL Server e MySQL.
NFR11: Em caso de falha da Chronos, o sistema deve degradar de forma controlada, preservando a operacao existente e registrando o erro para diagnostico posterior.
NFR12: A classificacao funcional de titulos Chronos deve ser deterministica e reproduzivel para o mesmo conjunto de dados de entrada.
NFR13: Um mesmo titulo Chronos nao pode ser apresentado simultaneamente em mais de um grid funcional na mesma visao consolidada.
NFR14: A feature deve preservar integralmente a logica operacional atual da Bralar enquanto adiciona a origem Travessia.
NFR15: A integracao Chronos deve respeitar o contrato real da API, incluindo autenticacao OAuth2 Client Credentials e uso correto dos identificadores internos necessarios para consulta de parcelas.
NFR16: A integracao deve tolerar respostas vazias, campos nulos, contratos sem parcelas e outros cenarios legitimos da API sem falha catastrofica.
NFR17: O sistema deve normalizar identificadores como cpf_cnpj e referencias operacionais necessarias para cruzamento entre SQL Server, MySQL e Chronos.
NFR18: A implementacao nao deve exigir alteracao nas queries SQL Server existentes para entregar o MVP.
NFR19: O sistema deve gerar rastros tecnicos suficientes para explicar origem, regra de classificacao e falhas de integracao de titulos Chronos durante homologacao e suporte.
NFR20: A equipe deve conseguir verificar, para um titulo homologado, se ele foi enquadrado por quebra, 30 dias ou renegociacao, e com base em qual criterio funcional.
NFR21: O sistema deve permitir comparacao homologada entre o que a Chronos retorna, o que o MySQL marca e o que o dashboard exibe, sem depender apenas de interpretacao manual informal.
NFR22: A identificacao visual Travessia/Bralar deve ser consistente em todos os pontos do MVP onde o titulo for exibido ao usuario.
NFR23: A inclusao da origem Travessia/Bralar e de eventuais novos campos nao pode prejudicar a leitura operacional dos grids existentes.
NFR24: A diferenciacao visual de origem nao deve depender exclusivamente de cor; ela deve incluir texto legivel ao usuario.
NFR25: Os filtros, buscas e a navegacao atuais do dashboard devem continuar compreensiveis e operaveis sem necessidade de treinamento adicional para o uso basico da nova feature.
NFR26: Toda a implementacao inicial deve ser validada integralmente em cobranca-hml antes de qualquer tentativa de publicacao em producao.
NFR27: A solucao deve permitir ativacao controlada e reversivel da integracao Chronos sem exigir cirurgia manual em banco ou codigo de producao.
NFR28: A homologacao deve incluir amostras reais de contratos Travessia para validar classificacao, nao duplicidade e consistencia entre grids e indicadores.
NFR29: Nenhuma alteracao em scripts SQL Server existentes pode ser introduzida sem confirmacao explicita do responsavel de negocio.
NFR30: O enriquecimento de dados Travessia via SQL Server deve preservar a identidade original do titulo na Chronos, evitando que consultas por cpf_cnpj substituam ou colapsem parcelas distintas de um mesmo cliente.
NFR31: A classificacao de titulos pagos da Travessia em advogado e renegociacoes deve ser mutuamente exclusiva e reproduzivel, para que cards e grids nunca somem o mesmo titulo duas vezes.
/var/www/html/cobranca-hml.TituloConsolidado, em vez de replicar regra por endpoint.cpf_cnpj, titulo_uid, proposta_exibicao, marca_empresa e origem_sistema.titulo_uid deve derivar de origem + credit_id + parcel_id; para Bralar, pode derivar de origem + proposta + cpf_cnpj + categoria.cobranca_30dias_registros, com campos candidatos origem_sistema, marca_empresa, titulo_uid, chronos_credit_id e chronos_parcel_id.cURL.quebras_listar.php, pc_titulos_pagos.php, pc_titulos_pagos_30d.php e indicadores_30dias.php.quebras, incluindo src/contatos/historico_clientes.php, js/dashboard_quebras.js, js/juridico_status_helper.js e src/api/triagem/registrar_historico.php.dashboard_cobrador.php deve continuar funcionando sobre a visao consolidada, consultando SQL Server, MySQL e Chronos quando o grid exigir.nome_cliente, cpf_cnpj, proposta_exibicao e referencias operacionais compatíveis.cobranca_atribuicao_cliente, considerando apenas atribuicoes ATIVO.cobranca_atribuicao_cliente continua sendo a fonte unica de ownership da carteira para Bralar e Travessia.contract_external_id explícito para ações jurídicas, evitando parsing implícito da proposta exibida.cpf_cnpj e referencias derivadas para enriquecer contexto exibivel de Travessia, sem substituir credit_id + parcel_id como identidade do titulo.B azul para Bralar e T verde para Travessia.30 dias continua exclusiva do grid Quebras.cobranca-hml, com rollout controlado e reversivel.| Epic | FRs Cobertos |
|---|---|
| Epic 1 - Fundacao da Carteira Consolidada | FR1, FR2, FR3, FR4, FR5, FR9, FR10, FR11, FR35, FR36, FR38, FR39, FR40, FR41, FR42, FR43, FR44, FR45, FR46, FR48, FR49 |
| Epic 2 - Quebras e Acoes Operacionais | FR12, FR13, FR14, FR15, FR16, FR17, FR18, FR31, FR32, FR33, FR34, FR37 |
| Epic 3 - Fluxo 30 Dias Unificado | FR19, FR20, FR21, FR22, FR23, FR27, FR28, FR29, FR30 |
| Epic 4 - Renegociacoes e Recebimentos Consolidados | FR24, FR25, FR26, FR27, FR28, FR29, FR30, FR45, FR47, FR48, FR49 |
| Epic 5 - Homologacao, Observabilidade e Rollout | FR31, FR32, FR33, FR34, FR38, FR39, FR40, FR41, FR42, FR43, FR44, FR46 |
Criar a camada backend que consolida Bralar e Travessia com ownership por carteira, identidade normalizada do titulo, classificacao deterministica e enriquecimento controlado por SQL Server quando a Chronos nao trouxer contexto suficiente.
As a desenvolvedor do sistema, I want uma camada backend dedicada para autenticar e consultar a Chronos, So that a aplicacao consuma a nova fonte sem expor segredos e sem espalhar regra HTTP pelos endpoints.
Acceptance Criteria:
Given um ambiente com configuracao Chronos habilitada When o backend precisar consultar creditos ou parcelas Then ele deve obter token OAuth2 no backend e reutiliza-lo com cache tecnico curto And nenhum token ou segredo pode ser enviado ao frontend ou logado integralmente.
As a cobrador logado, I want ver apenas titulos dos clientes da minha carteira, So that a Travessia siga exatamente a mesma regra operacional da Bralar.
Acceptance Criteria:
Given um usuario autenticado
When a camada consolidada carregar titulos Chronos
Then ela deve validar cada cpf_cnpj em cobranca_atribuicao_cliente com status = 'ATIVO'
And nenhum titulo Travessia fora da carteira ativa do usuario deve entrar nos grids do cobrador.
TituloConsolidadoAs a backend maintainer, I want um view model unico para Bralar e Travessia, So that os endpoints atuais consumam dados uniformes e previsiveis.
Acceptance Criteria:
Given dados vindos de SQL Server, MySQL e Chronos
When a camada consolidada montar uma linha funcional
Then ela deve produzir no minimo titulo_uid, origem_sistema, marca_empresa, cpf_cnpj, proposta_exibicao, datas relevantes, valor e categoria funcional
And para Travessia a identidade do titulo deve preservar credit_id + parcel_id, sem ser substituida por CPF.
As a usuario operacional, I want que linhas Travessia tenham contexto equivalente ao da Bralar, So that grids e acoes continuem completos mesmo quando a API nao trouxer todos os campos.
Acceptance Criteria:
Given um titulo Travessia com campos faltantes no payload Chronos
When a camada de enriquecimento for acionada
Then o sistema deve buscar no SQL Server por cpf_cnpj e referencias operacionais derivadas para completar contexto exibivel
And esse enriquecimento nao pode trocar a identidade original do titulo Chronos.
Adaptar o fluxo de quebras para exibir Bralar e Travessia na mesma experiencia operacional, mantendo filtros, busca, badge de origem e acoes por linha.
As a cobrador,
I want ver titulos Bralar e Travessia em Quebras,
So that eu trate a carteira completa no mesmo grid.
Acceptance Criteria:
Given titulos Bralar e Travessia elegiveis para quebras
When o grid for carregado
Then os registros devem ser exibidos juntos com a mesma estrutura visual atual
And cada linha deve mostrar badge inicial B azul ou T verde sem alterar a ordem das colunas.
As a cobrador, I want continuar buscando por cliente, residencial, proposta e documento, So that a nova fonte nao quebre meu modo atual de localizar registros.
Acceptance Criteria:
Given filtros e campo de busca da tela atual
When o usuario executar a busca em Quebras
Then o backend deve consultar a visao consolidada usando SQL Server, MySQL e Chronos quando necessario
And o resultado deve retornar como uma unica lista coerente.
As a cobrador, I want abrir o historico do cliente a partir de uma linha Travessia, So that eu continue tendo a mesma acao de consulta por CPF.
Acceptance Criteria:
Given uma linha Travessia em Quebras
When o usuario clicar em Histórico do cliente
Then a tela deve abrir com ownership e historicos MySQL preservados
And o sistema deve completar contexto do cliente com fallback de enriquecimento quando o SQL Server nao trouxer tudo diretamente pela rota atual.
contract_external_idAs a cobrador, I want sinalizar clientes Travessia para triagem juridica, So that o fluxo externo continue funcional para ambas as origens.
Acceptance Criteria:
Given uma linha Bralar ou Travessia em Quebras
When o usuario acionar a triagem juridica
Then o payload deve enviar cpf, contract_external_id, cliente e residencial corretos
And o fluxo nao deve depender de parsing fragil da proposta exibida.
Garantir que a marcacao, persistencia, reconhecimento e exibicao do fluxo 30 dias funcionem para Bralar e Travessia com o MySQL como fonte de verdade operacional.
30 dias para Bralar e TravessiaAs a cobrador,
I want usar o mesmo botao 30 dias em linhas Bralar e Travessia,
So that a minha operacao nao mude com a nova fonte.
Acceptance Criteria:
Given uma linha elegivel no grid Quebras
When o usuario confirmar a marcacao 30 dias
Then o sistema deve registrar o evento no MySQL com a mesma experiencia atual
And para Travessia deve persistir tambem rastreabilidade suficiente para identificar o titulo real da Chronos.
As a cobrador,
I want o grid indicar corretamente quando um titulo ja foi marcado em 30 dias,
So that eu nao registre a mesma parcela duas vezes por engano.
Acceptance Criteria:
Given registros presentes em cobranca_30dias_registros
When o grid Quebras for renderizado
Then a verificacao de flag deve usar chave operacional suficiente para distinguir parcelas diferentes
And o frontend deve refletir corretamente estado ja registrado para Bralar e Travessia.
As a cobrador,
I want ver no grid Recebimentos 30 Dias os titulos Travessia pagos e vinculados,
So that o fluxo fique completo apos a marcacao.
Acceptance Criteria:
Given registros pagos em cobranca_30dias_registros
When o grid Recebimentos 30 Dias for carregado
Then linhas Travessia devem ser montadas a partir da rastreabilidade Chronos e do enriquecimento SQL Server
And o grid deve manter a mesma leitura operacional da implementacao atual.
As a gerencia e cobrador,
I want que cards e calculos de comissao considerem a Travessia corretamente,
So that os totais continuem coerentes com o grid de 30 dias.
Acceptance Criteria:
Given registros Bralar e Travessia marcados e pagos no fluxo 30 dias
When os indicadores do dashboard forem calculados
Then os totais devem refletir a base MySQL consolidada
And a inclusao da Travessia nao pode duplicar nem inflar valores ja exibidos em outros grids.
Incluir titulos pagos da Travessia em renegociacoes e cards de recebimentos, preservando exclusao de duplicidade com 30 dias e mantendo contexto operacional completo.
As a cobrador, I want ver renegociacoes Travessia no mesmo grid das atuais, So that eu acompanhe recebimentos renegociados sem usar sistema paralelo.
Acceptance Criteria:
Given parcelas Chronos pagas com parcelFrequencyName = Renegociação
When o grid Renegociações Recebidas for carregado
Then os titulos elegiveis devem aparecer com contexto equivalente ao da Bralar
And itens ja pertencentes a 30 dias nao podem aparecer novamente neste grid.
Recebimentos por tipo e Total RecebimentosAs a gerencia, I want cards coerentes com os grids pagos, So that os totais agregados batam com a visao operacional homologada.
Acceptance Criteria:
Given dados consolidados de renegociacoes, 30 dias e advogado
When os cards do dashboard forem calculados
Then os titulos Travessia devem entrar apenas nas categorias suportadas pelo MVP
And a soma dos cards homologados deve permanecer coerente com as linhas dos grids correspondentes.
As a cobrador,
I want ver no grid Recebimentos Advogado os titulos Travessia elegiveis,
So that a classificacao paga fique completa sem consulta paralela.
Acceptance Criteria:
Given titulos pagos da Travessia no periodo consultado
When o enriquecimento no SQL Server indicar NumeroContratoBanco LIKE '%adv%'
Then esses titulos devem ser exibidos no grid Recebimentos Advogado
And os mesmos titulos nao podem ser exibidos simultaneamente em 30 dias ou renegociacoes.
Fechar a feature com rastreabilidade funcional, validacao em homologacao e ativacao reversivel, deixando a operacao pronta para publicar com seguranca quando aprovada.
As a analista de homologacao, I want entender por que cada titulo entrou em determinado grid, So that eu consiga validar e depurar divergencias com precisao.
Acceptance Criteria:
Given um titulo homologado When a equipe precisar investigar sua classificacao Then devem existir rastros suficientes para identificar origem, regra aplicada, ownership e enriquecimento usado And esses logs nao podem expor segredos ou dados sensiveis desnecessarios.
As a responsavel tecnico, I want ativar ou desativar a integracao Chronos de forma controlada, So that a homologacao e eventual publicacao tenham rollback simples.
Acceptance Criteria:
Given flags de ambiente da feature When a Chronos estiver indisponivel ou a feature precisar ser revertida Then o dashboard deve continuar operando com a base Bralar atual And a omissao da Travessia deve ser controlada e registrada em log.
cobranca-hmlAs a usuario de negocio, I want validar contratos reais da Travessia no ambiente de homologacao, So that a publicacao futura ocorra com evidencia funcional suficiente.
Acceptance Criteria:
Given contratos reais conhecidos da Travessia
When a equipe homologar quebras, 30 dias, renegociacoes, botoes de acao e cards
Then os resultados devem ser comparaveis com Chronos, MySQL e SQL Server
And divergencias relevantes devem ficar documentadas antes de qualquer liberacao para producao.