Painel de leitura da documentação, planejamento e implementação por feature, com seleção centralizada antes da navegação.
stepsCompleted:
Author: Thiago Date: 2026-04-09
Esta feature evolui o sistema de cobranca existente para incorporar titulos da Chronos ao fluxo operacional ja utilizado pela equipe, sem substituir a logica atual do ERP e sem alterar scripts SQL Server sem validacao previa. O objetivo e eliminar a lacuna operacional causada pelos titulos suspensos no ERP, que hoje nao aparecem no dashboard_cobrador.php nem alimentam corretamente indicadores, grids de quebra, recebimentos 30 dias e renegociacoes. A feature deve permitir que o cobrador trabalhe toda a carteira relevante no mesmo sistema, com comportamento consistente entre Bralar e Travessia, reduzindo consulta paralela, risco de decisao baseada em carteira incompleta e divergencias entre cards e grids.
O escopo funcional confirmado cobre a inclusao da nova origem de dados Chronos nos fluxos do painel do cobrador que dependem de titulos em aberto e pagos, preservando o modelo atual de operacao. Titulos da Chronos representam a marca Travessia; titulos das fontes ja existentes permanecem Bralar. No grid, todos os titulos devem ser listados; nos indicadores, os valores devem ser somados. A classificacao funcional da Chronos deve obedecer exatamente as regras validadas: quebras por parcelas OVERDUE; 30 dias por vinculo existente no MySQL cobranca_30dias_registros; advogado para titulos pagos cujo contexto enriquecido no SQL Server indique NumeroContratoBanco LIKE '%adv%'; e renegociacoes para titulos pagos remanescentes com parcelFrequencyName = Renegociação. Um mesmo titulo nao pode entrar em mais de um grid.
O diferencial desta feature nao e apenas consumir uma API externa, mas completar o processo de cobranca sem criar um fluxo paralelo e sem desestabilizar a operacao existente. A solucao precisa integrar uma terceira fonte de dados em um sistema brownfield sensivel, no qual SQL Server e fonte operacional principal, MySQL sustenta marcacoes e controles internos, e a tela do cobrador depende de consistencia entre varias consultas distintas. O valor real da feature esta em manter a ergonomia operacional atual enquanto amplia a visao da carteira com titulos que hoje ficam invisiveis no ERP.
O insight central e que a Chronos nao deve ser tratada como substituta do ERP, e sim como fonte complementar para titulos que o ERP exclui pela regra de SuspenderFaturamento = 0. Por isso, a implementacao correta exige consolidacao no backend, e nao alteracao das queries atuais do SQL Server. Essa abordagem preserva a confiabilidade das regras existentes, reduz risco de regressao e viabiliza rollout controlado em homologacao com comparacao de resultados antes da ativacao plena.
web_appfintechhighbrownfieldTrata-se de uma evolucao de aplicacao web interna server-rendered, com APIs JSON internas, voltada a cobranca e recebiveis. A complexidade e alta porque a feature afeta operacao em producao, cruza SQL Server, MySQL e Chronos, depende de classificacao correta por status e marcacoes auxiliares, e exige consistencia entre dashboards, grids, indicadores e acoes operacionais do cobrador.
O cobrador deve conseguir operar a carteira ampliada dentro do dashboard_cobrador.php sem recorrer a consultas paralelas em sistemas externos para identificar titulos relevantes da Travessia. Os titulos da Chronos devem aparecer no mesmo fluxo operacional ja conhecido pela equipe, com comportamento aderente ao modelo atual dos grids e indicadores. O usuario deve conseguir reconhecer claramente a origem Travessia ou Bralar em cada titulo exibido, sem ambiguidade de classificacao visual ou funcional.
O fluxo operacional deve permanecer familiar: o usuario continua usando os grids de quebras, renegociacoes e 30 dias com as mesmas expectativas de uso, mas agora com maior cobertura da carteira real. O botao de registrar 30 dias no grid de quebras deve continuar funcional para os clientes elegiveis da nova origem, de modo que o processo operacional diario nao seja fragmentado entre fontes distintas.
A feature sera considerada bem-sucedida se ampliar a visao da carteira sem remover ou distorcer os dados atuais da Bralar. Nenhum titulo atualmente exibido pela logica vigente deve desaparecer como efeito colateral da integracao Chronos. Titulos da nova origem devem ser enquadrados corretamente em apenas um grid por vez, evitando inflacao artificial de valores ou contagens.
Os totais dos cards e os totais dos grids devem permanecer coerentes entre si apos a consolidacao. A homologacao de negocio deve comprovar que a carteira exibida no sistema passa a refletir corretamente os titulos suspensos que hoje nao aparecem no ERP, com validacao amostral manual contra a Chronos e contra os marcadores existentes no MySQL auxiliar.
Nao deve haver alteracao em scripts SQL Server existentes sem aprovacao explicita do responsavel de negocio. A integracao Chronos deve ser implementada como camada complementar no backend, preservando a logica atual do ERP e reduzindo risco de regressao. O sistema deve continuar operando mesmo em caso de indisponibilidade da API Chronos, priorizando continuidade da aplicacao com degradacao controlada da nova origem.
Toda a implementacao inicial deve ocorrer e ser validada em cobranca-hml, com isolamento de MySQL, uploads e dominio. O rollout para producao deve poder ser revertido por configuracao, sem cirurgia manual em codigo ou banco. A classificacao funcional da primeira entrega deve obedecer exatamente as regras validadas: OVERDUE em quebras; PAID com vinculo no cobranca_30dias_registros em 30 dias; PAID com enriquecimento SQL Server indicando NumeroContratoBanco LIKE '%adv%' em advogado; e PAID com parcelFrequencyName = Renegociação, fora de 30 dias e advogado, em renegociacoes.
100% dos contratos de teste selecionados para homologacao manual devem aparecer no grid correto conforme a regra validada.0 titulos da Chronos devem aparecer simultaneamente em mais de um grid funcional na mesma visao consolidada.0 regressao e aceita para os titulos atualmente exibidos pela logica Bralar.100% dos titulos originados da Chronos exibidos ao usuario devem ser marcados como Travessia.100% dos titulos das fontes atuais exibidos ao usuario devem permanecer marcados como Bralar.O MVP contempla a integracao da Chronos nas visoes de quebras, 30 dias, renegociacoes e advogado, com consolidacao no backend e sem alteracao das queries SQL Server atuais. O backend deve incorporar os titulos da nova origem usando classificacao funcional confirmada, respeitando as marcacoes existentes no MySQL, o enriquecimento via SQL Server e preservando o comportamento operacional atual do cobrador. O MVP tambem inclui a identificacao visual Travessia/Bralar, homologacao completa em cobranca-hml e capacidade de rollback por configuracao.
A fase posterior ao MVP deve incluir ampliacao de logs comparativos e auditoria de consolidacao, e eventuais otimizacoes de performance como cache e pre-processamento da origem externa. Tambem entram nessa fase refinamentos de observabilidade, monitoramento de falha da API e melhorias de reconciliacao entre cards, grids e acoes operacionais.
A visao futura e transformar o sistema em uma camada unica e reutilizavel de titulos consolidados para toda a operacao de cobranca, reduzindo a dependencia de regras espalhadas por endpoint e permitindo que novas origens de dados sejam agregadas sem reescrever fluxos operacionais. Nessa visao, Bralar e Travessia passam a compartilhar um mesmo modelo de leitura operacional, com classificacao consistente, rastreabilidade de origem e reaproveitamento da mesma camada por dashboards, acompanhamentos, relatorios e automacoes futuras.
O cobrador inicia seu dia no dashboard_cobrador.php esperando encontrar todos os titulos relevantes da sua carteira. Antes da feature, ele enxerga apenas a parte da carteira que o ERP expunha pela regra atual, e os titulos suspensos da Travessia ficam invisiveis no fluxo principal. Isso gera consulta paralela, incerteza sobre a situacao real do cliente e risco de deixar de atuar em titulos relevantes.
Com a feature ativa, o cobrador continua entrando na mesma tela e usando os mesmos grids, mas agora passa a ver tambem os titulos da Chronos classificados como Travessia. O ponto de valor da jornada e que nada muda na forma de operar: a diferenca e que a carteira finalmente aparece de forma mais completa, dentro do sistema que ele ja domina. O momento de sucesso dessa jornada e quando o cobrador percebe que nao precisa mais recorrer a outro sistema para entender se aquele cliente possui titulos pendentes ou recebidos fora da visao atual do ERP.
Essa jornada exige capacidades claras: consolidacao backend entre ERP, MySQL e Chronos; identificacao visual de origem; e preservacao do comportamento atual dos grids para que a ampliacao da carteira nao produza estranhamento operacional.
O cobrador encontra um titulo da Travessia inicialmente enquadrado em quebra, porque ele esta vencido e em aberto. A partir da operacao do dia, ele precisa usar o mesmo botao de registrar 30 dias que ja utiliza hoje com os titulos atuais. O sistema deve aceitar esse cliente da nova origem, marcar corretamente no MySQL e fazer com que os proximos estados operacionais reflitam essa marcacao sem exigir fluxo paralelo ou excecao manual.
O momento critico da jornada acontece quando esse titulo deixa de ser apenas uma quebra e passa a pertencer ao fluxo de 30 dias ou, se pago como renegociacao, ao fluxo de renegociacoes. O cobrador nao quer entender a origem tecnica do dado; ele quer confiar que, ao agir sobre o titulo, o sistema vai reposiciona-lo no grid certo. O sucesso dessa jornada acontece quando o usuario consegue tratar um titulo Travessia com a mesma naturalidade com que trata um titulo Bralar.
Essa jornada exige rastreabilidade de classificacao, escrita correta em cobranca_30dias_registros, regra de exclusao de duplicidade entre grids e consistencia entre status da parcela na Chronos e marcacoes auxiliares no MySQL.
O usuario de gerencia precisa confiar que a carteira consolidada nao so ficou mais completa, mas tambem permaneceu coerente nos indicadores. Ele nao olha apenas linhas individuais; ele precisa confrontar cards, grids de recebimento, acompanhamento 30 dias e totais agregados para garantir que a integracao nao inflou valores, nao duplicou titulos e nao ocultou registros atuais.
Na pratica, a gerencia quer conseguir validar que a inclusao da Travessia melhora a visao operacional sem desorganizar os numeros que sustentam acompanhamento e decisao. O clímax dessa jornada ocorre quando ela compara amostras conhecidas da carteira e constata que os titulos da Chronos entraram no sistema no lugar funcional correto, com totais coerentes e sem regressao para a Bralar.
Essa jornada exige capacidade de conciliacao entre cards e grids, classificacao deterministica por grid, e visibilidade suficiente para homologar com confianca a carteira consolidada antes de qualquer publicacao em producao.
Em algum momento de homologacao ou operacao assistida, um analista de negocio ou suporte funcional encontra um titulo que parece estar no grid errado, nao aparece onde o usuario esperava ou diverge da consulta manual na Chronos. O papel desse usuario nao e desenvolver, mas entender rapidamente por que aquele titulo foi classificado como quebra, 30 dias ou renegociacao, e qual fonte de dados determinou esse comportamento.
O sistema precisa oferecer um modelo previsivel o suficiente para que essa investigacao nao vire adivinhacao. O analista deve conseguir verificar origem do titulo, status da parcela na Chronos, vinculo no MySQL e regra aplicada, sem reabrir discussao conceitual a cada caso. O sucesso dessa jornada acontece quando divergencias podem ser explicadas e corrigidas com base em regra documentada, e nao em interpretacao subjetiva.
Essa jornada exige contrato interno de dados consolidado, logs e/ou campos de rastreio da origem e classificacao, e regras de enquadramento suficientemente explicitas para suportar homologacao e manutencao futura.
Do ponto de vista tecnico-operacional, a aplicacao precisa continuar util mesmo quando a Chronos estiver lenta, indisponivel ou retornando erro. O sistema atual nao pode perder sua funcionalidade principal por causa da nova origem complementar. Em um ambiente brownfield critico, degradacao controlada vale mais do que dependencia fragil.
Nessa jornada, o backend tenta consumir a Chronos, encontra falha e precisa decidir o comportamento correto: registrar erro, omitir a fonte complementar naquele momento e manter os dados atuais operando, sem quebrar sessao, dashboard ou navegacao do usuario. O momento de sucesso e silencioso: o sistema continua funcionando, e a equipe tecnica ganha insumos para diagnosticar a falha sem expor erro catastrófico ao cobrador.
Essa jornada exige tratamento resiliente da integracao, isolamento da nova fonte, possibilidade de rollout por configuracao e observabilidade suficiente para validar disponibilidade e comportamento da API sem comprometer a operacao existente.
As jornadas revelam um conjunto claro de capacidades obrigatorias para a feature. Primeiro, o sistema precisa de uma camada unificada de consolidacao de titulos que aceite ERP, MySQL e Chronos como insumos e produza um contrato comum para os grids e indicadores do dashboard. Segundo, a classificacao funcional deve ser deterministica e auditavel, com regras explicitas para quebras, 30 dias e renegociacoes, de forma que o comportamento seja reproduzivel e verificavel.
Tambem fica evidente a necessidade de compatibilidade operacional: a feature deve manter o mesmo fluxo mental do cobrador, o mesmo mecanismo de marcacao de 30 dias e a mesma capacidade da gerencia de validar numericamente a carteira. Por fim, as jornadas confirmam requisitos transversais de resiliencia e rastreabilidade: identificacao visual de origem Travessia/Bralar, nao duplicidade entre grids, rollback por configuracao, logs de integracao e explicabilidade da regra aplicada em cada titulo consolidado.
Mesmo sem tratar adquirencia, cartao ou open finance, esta feature opera em um contexto fintech de cobranca e recebiveis, com impactos diretos sobre valores devidos, recebimentos, renegociacoes e trilhas operacionais usadas pela equipe. Por isso, os requisitos de dominio precisam privilegiar integridade de calculo, rastreabilidade e capacidade de auditoria funcional. A principal exigencia regulatoria pratica aqui nao e uma certificacao nova, e sim garantir que a aplicacao mantenha coerencia entre fonte externa, banco auxiliar e visao operacional exibida ao usuario.
Os dados tratados incluem identificadores pessoais e financeiros, especialmente cpf_cnpj, nome do devedor, contrato/proposta, vencimento, pagamento e valor. Portanto, a feature deve seguir o mesmo padrao de minimizacao de exposicao ja esperado para dados pessoais no sistema: exibir apenas o necessario para a operacao, evitar vazamento de credenciais, impedir que tokens Chronos fiquem versionados no repositorio e preservar logs de auditoria sem despejar segredos ou payloads sensiveis completos de forma indiscriminada. Como a carteira consolidada altera a visao gerencial e operacional, o sistema tambem precisa sustentar explicabilidade suficiente para auditoria interna: origem do titulo, regra de enquadramento aplicada e motivo da presenca no grid devem ser rastreaveis.
A restricao tecnica mais importante desta feature ja foi definida pelo negocio e e obrigatoria: nao alterar scripts SQL Server existentes sem confirmacao explicita. Isso significa que a integracao Chronos nao pode ser resolvida por “correcao” das consultas atuais do ERP; ela precisa ser implementada como camada complementar no backend PHP, preservando a regra atual de SuspenderFaturamento = 0 e agregando apenas os titulos que hoje ficam fora da visao do dashboard. Essa restricao molda toda a arquitetura da solucao.
A consolidacao tambem precisa respeitar a natureza heterogenea das fontes. O SQL Server continua sendo a fonte principal do comportamento atual da Bralar. O MySQL continua sendo a fonte de marcacoes operacionais, especialmente cobranca_atribuicao_cliente e cobranca_30dias_registros. A Chronos passa a ser fonte complementar da Travessia. Como essas fontes nao compartilham o mesmo identificador tecnico de titulo, a solucao precisa separar claramente tres niveis de identidade: cpf_cnpj para pertencimento do cliente/carteira, identificador de titulo/parcela da Chronos para granularidade de linha, e proposta como referencia operacional visivel para exibicao e marcacao.
Essa regra de pertencimento da carteira precisa continuar sendo resolvida pelo MySQL, e nao pela Chronos. Antes de qualquer titulo Travessia entrar em quebras, renegociacoes, 30 dias ou indicadores derivados da visao do cobrador, o backend deve validar o cpf_cnpj do devedor contra cobranca_atribuicao_cliente, considerando apenas atribuicoes com status = 'ATIVO'. A API externa fornece titulos; o MySQL continua sendo a fonte unica de verdade de quem e o cobrador responsavel pelo cliente.
A aplicacao tambem precisa permanecer resiliente. A Chronos e uma dependencia externa com OAuth2 Client Credentials, latencia variavel e possibilidade de falha transitoria. O comportamento aceitavel em caso de erro e degradacao controlada: o dashboard e os endpoints atuais continuam respondendo com os dados ja existentes, a nova fonte pode ser omitida naquele ciclo, e a falha deve ser registrada em log tecnico sem derrubar sessao, pagina ou grid. Em outras palavras, disponibilidade operacional vale mais do que completude instantanea da fonte complementar.
As credenciais client_id e client_secret da Chronos nao podem ficar hardcoded em endpoints, views, JavaScript ou arquivos versionados de configuracao sensivel. Elas devem permanecer apenas em configuracao de ambiente do servidor de homologacao e, futuramente, de producao. O backend deve ser o unico responsavel por solicitar token OAuth2, consumir a API externa e devolver ao frontend apenas o dado consolidado necessario para a tela. Nenhuma chamada direta do navegador para a Chronos deve ser introduzida.
A feature tambem exige cuidado com logging. Logs precisam ser suficientes para diagnosticar falhas de autenticacao, timeout, erro HTTP e divergencia de classificacao, mas sem expor token, client_secret ou dumps integrais de payload em arquivos acessiveis indiscriminadamente. O nivel correto de rastreio e registrar metadados funcionais: endpoint chamado, credito consultado, quantidade de parcelas retornadas, status relevante, criterio de classificacao aplicado e mensagem de erro resumida quando houver excecao.
Como a feature altera cards e grids usados para acompanhamento diario, ela precisa sustentar auditoria funcional suficiente para homologacao e manutencao. Cada titulo consolidado da Chronos deve ter origem claramente identificavel como Travessia, e a regra que o colocou em quebras, 30 dias ou renegociacoes precisa ser deterministica. Na pratica, isso significa que o backend deve ser capaz de explicar, para um caso concreto, se o titulo entrou por status = OVERDUE, por vinculo em cobranca_30dias_registros, ou por parcelFrequencyName = Renegociação.
Tambem ha exigencia de nao duplicidade auditavel. Um mesmo titulo Chronos nao pode aparecer em mais de um grid funcional na mesma visao consolidada. Por isso, a consolidacao deve aplicar ordem de precedencia clara entre classificacoes pagas e abertas, registrar o motivo do enquadramento e manter chaves tecnicas suficientes para rastrear casos de conflito. Esse requisito nao e apenas tecnico; ele e essencial para que a gerencia consiga confiar nos totais da carteira homologada.
Do ponto de vista de integracao, a Chronos deve ser tratada como origem de creditos e parcelas, nao como substituta do ERP. O consumo minimo necessario para o MVP ja esta claro: autenticacao OAuth2, leitura de creditos para localizar o id interno do contrato, e leitura de parcelas por credito para classificar linhas por status e frequencia. A implementacao precisa respeitar o comportamento real observado na API: GET /v1/credits/{id}/parcels usa o id interno da Chronos, e nao o contractNumber; parcelFrequencyName pode assumir mais de um valor, incluindo Mensal, Intermediaria e Renegociação; status das parcelas e o marcador principal para separar aberto de pago.
O MySQL permanece como fonte obrigatoria de orquestracao operacional. Em especial, a elegibilidade de 30 dias nao deve ser reinventada na Chronos; ela continua sendo definida por cobranca_30dias_registros. Isso impõe um padrao de integracao em duas etapas para titulos pagos da Travessia: primeiro identificar os pagos na Chronos; depois cruzar esses titulos/clientes com a marcacao existente no MySQL para decidir se entram em 30 dias; se nao entrarem em 30 dias, ainda podem entrar em renegociacoes se parcelFrequencyName = Renegociação. O endpoint consolidado precisa respeitar essa regra para evitar dupla contagem entre grids.
O mesmo principio vale para todos os grids filtrados pelo usuario logado. A feature nao pode introduzir um segundo conceito de carteira baseado em payload da Chronos, nome de cobrador ou qualquer outra inferencia externa. A camada consolidada deve carregar o mapa cpf_cnpj -> cobrador_usuario_id a partir de cobranca_atribuicao_cliente, normalizar o documento para somente digitos e incluir titulos Chronos apenas quando o CPF estiver atribuido ao usuario correto. Para gerencia e visoes agregadas, a mesma tabela continua sendo a referencia oficial de ownership da carteira.
O padrao correto para este dominio e consolidacao server-side com contrato interno comum. Cada endpoint do dashboard deve consumir um modelo normalizado de titulo, contendo no minimo origem, marca (Travessia/Bralar), identificador tecnico, proposta exibivel, cpf_cnpj, nome, residencial, valor, data relevante e categoria funcional. Esse padrao reduz espalhamento de regra e evita que a Chronos seja tratada de maneira improvisada em cada grid.
O principal anti-pattern a evitar e replicar a logica da Chronos diretamente na camada de apresentacao ou copiar trechos de classificacao de forma independente em varios endpoints. Isso criaria divergencia entre cards e grids, dificultaria auditoria e aumentaria o risco de uma correcao em um endpoint nao ser refletida nos demais. Outro anti-pattern seria deduplicar linhas apenas por cpf_cnpj, colapsando titulos distintos do mesmo cliente. O CPF e chave de pertencimento; a linha operacional continua sendo o titulo/parcela.
Embora o foco nao seja fraude financeira classica, existe um risco claro de integridade operacional: inflar carteira, esconder titulo elegivel, ou enquadrar parcela no grid errado por erro de cruzamento entre fontes. O sistema precisa tratar isso como risco de negocio. Toda regra de classificacao deve ser deterministica, aplicada na mesma ordem e documentada no PRD e na futura arquitetura. Campos vazios, respostas parciais, creditos sem parcelas e parcelas com status inesperado precisam ser tratados como cenarios validos de dominio, nao como excecoes improvaveis.
Tambem e importante proteger a qualidade da consolidacao contra variacoes de formato. O ERP, o MySQL e a Chronos podem representar proposta e documento com mascaras, zeros e convencoes distintas. A feature precisa normalizar cpf_cnpj para fins de cruzamento e usar identificador de parcela/titulo apropriado para granularidade de exibição, sem perder a proposta operacional mostrada ao usuario. Essa normalizacao e um requisito de dominio porque afeta diretamente a confiabilidade da carteira consolidada.
30 dias: mitigado por manter o MySQL como fonte de verdade da marcacao operacional.Em resumo, o dominio exige que a feature seja tratada menos como “consumo de API” e mais como consolidacao auditavel de carteira financeira-operacional. A qualidade da implementacao sera medida pela capacidade de preservar a operacao atual, incorporar a Travessia sem quebrar a Bralar e explicar com precisao por que cada titulo apareceu onde apareceu.
Esta feature pertence a um web_app brownfield, renderizado no servidor, com paginas PHP tradicionais e endpoints JSON consumidos pelo frontend do dashboard. O impacto principal ocorre em dashboard_cobrador.php, que ja centraliza indicadores, grids operacionais e acoes diarias do cobrador. Portanto, a implementacao precisa respeitar a natureza incremental da aplicacao atual: nada de reestruturar a tela para SPA, nada de mover a integracao para o navegador, e nada de criar um fluxo paralelo para a Travessia.
O melhor encaixe tecnico continua sendo backend-first. O PHP deve consolidar as fontes, os endpoints existentes devem manter contratos estaveis com o frontend, e a pagina do dashboard deve receber apenas os dados finais necessarios para exibir indicadores, grids e marcacoes de origem. Isso preserva o comportamento conhecido do sistema e reduz o risco de regressao visual ou funcional.
Como se trata de uma pagina operacional de uso diario, a arquitetura do web_app precisa privilegiar previsibilidade e resposta consistente. O dashboard nao depende de SEO, nao exige indexacao publica e nao precisa de experiencia em tempo real. O foco aqui e confiabilidade em sessao autenticada, carregamento aceitavel para equipe interna e capacidade de reprocessar filtros por data/nome sem quebrar a navegacao existente.
A feature deve ser implementada mantendo separacao clara entre camada de tela e camada de agregacao. O browser continua apenas solicitando endpoints internos do sistema. Os endpoints passam a chamar uma camada consolidada que combina SQL Server, MySQL e Chronos, devolvendo ao frontend um modelo uniforme. Essa abordagem reduz duplicacao de regra JavaScript/PHP e evita que cada grid invente sua propria classificacao.
Por ser um sistema interno de uso operacional, a prioridade de compatibilidade deve ser navegadores desktop modernos usados pela equipe, com foco pratico em Chrome e Edge atuais em ambiente corporativo. O suporte deve ser suficiente para manter filtros, modais, grids e acoes AJAX do dashboard sem regressao visual ou quebra de interacao. Nao ha justificativa para introduzir dependencias que exijam browsers mais novos do que o ambiente ja tolera hoje, nem para otimizar especificamente para navegadores legados se a aplicacao atual ja nao os considera alvo.
Como a feature acrescenta dados, e nao um novo paradigma de interface, a melhor estrategia e preservar os componentes existentes e limitar as mudancas visuais ao necessario: coluna ou badge de origem Travessia/Bralar, eventual informacao adicional de proposta consolidada e ajustes minimos de layout para acomodar os novos campos sem estourar largura ou leitura da grade.
Apesar de o uso principal ser desktop, a tela deve continuar funcional em resolucoes menores, porque o dashboard ja existe em producao e qualquer regressao de responsividade pode impactar consultas rapidas em notebook ou monitor menor. A feature nao precisa redesenhar a experiencia mobile, mas nao pode piorar a leitura de cards, filtros e grids por adicionar colunas sem planejamento.
Na pratica, isso significa que a inclusao de Travessia/Bralar deve usar um padrao visual compacto, e a exibicao de proposta/titulo da Chronos deve ser pensada para nao alongar a tabela desnecessariamente. Se for preciso acrescentar informacao nova, a prioridade e preservar legibilidade com truncamento controlado, tooltip ou reorganizacao leve de colunas, sem remodelar a pagina inteira.
Como o dashboard e tela de trabalho frequente, a integracao Chronos nao pode introduzir degradacao perceptivel excessiva no carregamento. O objetivo funcional deve ser manter tempos de resposta proximos do comportamento atual nas consultas mais usadas, aceitando pequeno custo adicional pela nova fonte, mas evitando consultas em cascata sem controle. O principal risco de performance esta no volume de creditos/parcels consultados na Chronos para cada carteira do cobrador.
Por isso, a implementacao precisa adotar limites claros de escopo por requisicao, filtros por carteira do usuario, normalizacao eficiente e, se necessario, pontos de cache tecnico ou memoizacao de curta duracao no backend. O desenho do web_app deve evitar chamadas redundantes da mesma tela para os mesmos dados da Chronos durante um mesmo fluxo de uso, especialmente quando cards e grids consultam periodos identicos.
SEO nao e relevante para esta feature. O dashboard e autenticado, operacional e de uso interno, portanto nao ha necessidade de indexacao publica, metadados de busca ou otimizacao para crawlers. Esse ponto e importante justamente para evitar distração: o investimento deve ficar em consistencia de dados, desempenho autenticado e rastreabilidade, nao em preocupacoes de pagina publica.
Mesmo sendo um sistema interno, a feature deve manter o nivel atual de acessibilidade operacional da interface. Isso significa nao depender exclusivamente de cor para indicar Travessia ou Bralar, preservar contraste legivel dos badges, nao quebrar navegacao por teclado em filtros e acoes principais, e manter textos e rotulos compreensiveis para o usuario que precisa interpretar rapidamente um grid operacional.
A exigencia aqui e pragmatica: o sistema nao precisa de um grande redesenho para WCAG completo nesta entrega, mas tambem nao pode introduzir uma marcacao visual que piore a leitura, esconda informacao importante ou crie ambiguidade funcional. A origem do titulo e a categoria operacional precisam ser percebidas de forma clara e redundante, com texto visivel e nao apenas cor ou icone.
Por ser um web_app existente, a implementacao deve priorizar contratos estaveis entre frontend e backend. Onde ja existir endpoint JSON consumido pelo dashboard, a preferencia e estender o contrato com novos campos compatíveis, em vez de reinventar rotas ou duplicar telas. A camada frontend deve sofrer o minimo de impacto possivel: pequenas adaptacoes para exibir origem e, quando necessario, proposta consolidada, enquanto a maior parte da inteligencia fica no backend.
Tambem e importante assumir explicitamente as respostas para as perguntas-chave do tipo de projeto, com base no sistema atual e nas decisoes ja tomadas:
MPA/server-rendered com AJAX pontual, nao SPA;Essas decisoes sao adequadas ao produto porque reforcam o objetivo real da feature: completar a carteira do cobrador com seguranca e previsibilidade, sem transformar o modo de funcionamento da aplicacao.
O PRD construido ate aqui aponta para um problem-solving MVP: a meta da primeira entrega nao e provar interesse abstrato, e sim resolver uma lacuna operacional concreta que hoje deixa a carteira incompleta no dashboard_cobrador.php. O sucesso do MVP depende de o cobrador conseguir trabalhar os titulos da Travessia no mesmo fluxo ja usado para a Bralar, com classificacao correta, sem sistema paralelo e sem regressao da operacao existente.
Essa estrategia de MVP e a mais adequada porque o problema ja esta validado pelo uso diario do sistema. Nao precisamos descobrir se existe dor; precisamos corrigir com seguranca uma falha de cobertura da carteira. O escopo inicial, portanto, deve privilegiar confiabilidade, explicabilidade e homologacao controlada, em vez de tentar entregar todas as categorias e otimizacoes de uma vez.
MVP Approach: problem-solving MVP com rollout em homologacao e validacao operacional por amostragem real.
Resource Requirements: o menor conjunto viavel para esta entrega e um responsavel tecnico backend/PHP com entendimento das consultas atuais, apoio funcional do usuario de negocio para validar contratos da Travessia e tempo reservado para homologacao comparativa em cobranca-hml. Nao ha dependencia de time de design ou infra adicional para a primeira entrega, alem da configuracao da Chronos e do ambiente de homologacao ja criado.
Core User Journeys Supported:
quebras, 30 dias e renegociacoes.Must-Have Capabilities:
quebras, 30 dias e renegociacoes.quebras, 30 dias, renegociacoes e advogado.OVERDUE => quebrasPAID + vinculo no cobranca_30dias_registros => 30 diasPAID + SQL Server enriquecido com NumeroContratoBanco LIKE '%adv%' => advogadoPAID + parcelFrequencyName = Renegociação e fora de 30 dias/advogado => renegociacoesTravessia/Bralar.30 dias no MySQL tambem para clientes Travessia.cobranca-hml antes de qualquer publicacao.Explicitamente Fora do MVP:
Phase 2 (Post-MVP):
Phase 3 (Expansion):
Technical Risks: o maior risco tecnico e introduzir divergencia entre grids/cards ou regressao nos dados atuais da Bralar. A mitigacao e manter as queries SQL Server intactas, encapsular a Chronos em camada complementar, aplicar classificacao centralizada e homologar com contratos reais antes de qualquer ativacao em producao. Outro risco tecnico forte e performance em consultas repetidas; a mitigacao inicial e limitar o escopo do MVP ao conjunto minimo de endpoints impactados e instrumentar logs de tempo/volume antes de otimizar.
Market Risks: o risco de mercado, neste caso, e mais propriamente risco de aderencia operacional: entregar algo tecnicamente integrado mas que o negocio nao reconheca como “carteira correta”. A mitigacao e validar o MVP por contratos e cenarios reais conhecidos da Travessia, confirmando enquadramento em quebras, 30 dias, advogado e renegociacoes com o usuario de negocio antes da liberacao.
Resource Risks: se houver menos tempo ou capacidade tecnica do que o ideal, o menor recorte ainda valido continua exigindo os grids operacionais completos ja confirmados, com especial cuidado para 30 dias, advogado e renegociacoes, pois qualquer corte parcial nesses fluxos pode duplicar valores ou distorcer indicadores. O que nao pode ser cortado sem invalidar o MVP e a classificacao correta por grid, a origem Travessia/Bralar, a marcacao 30 dias, a separacao de advogado e a homologacao segura em cobranca-hml.
Em termos de escopo, a avaliacao consolidada e esta: o projeto nao e pequeno, mas o MVP pode e deve ser enxuto. Ele precisa resolver a dor central com alta confiabilidade, sem carregar para a primeira entrega tudo o que seria desejavel a medio prazo. Esse recorte preserva velocidade, reduz risco e mantem o caminho aberto para evolucao posterior sobre uma base mais segura.
dashboard_cobrador.php os titulos da Chronos que pertencem aos clientes de sua carteira operacional.Travessia ou Bralar.cpf_cnpj.quebras quando estiverem em aberto e vencidos segundo a regra funcional validada.30 dias quando houver marcacao operacional correspondente no banco auxiliar.renegociacoes quando atenderem ao criterio funcional validado para renegociacao.quebras junto com os titulos ja existentes.quebras as informacoes operacionais necessarias para o tratamento do titulo, incluindo cliente, documento, proposta, residencial, valor e vencimento.quebras.quebras sem exigir fluxo paralelo ou consulta externa para completar a visao do cliente.quebras, os botões de ação de Histórico do cliente e Triagem Jurídica.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.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.cpf_cnpj e referencias operacionais derivadas, preservando a identidade original do titulo Chronos.30 dias usando o mesmo processo operacional ja existente.30 dias para clientes/titulos Travessia no banco auxiliar usado pela operacao atual.30 dias os titulos pagos da Travessia que tenham sido corretamente vinculados a esse fluxo.30 dias, independentemente da origem do titulo.30 dias nos indicadores e totais relacionados a esse fluxo.renegociacoes os titulos pagos da Travessia que se enquadrem na regra funcional de renegociacao.renegociacoes do fluxo de 30 dias, evitando dupla contagem e ambiguidade operacional.advogado os titulos pagos da Travessia cujo enriquecimento no SQL Server indique NumeroContratoBanco LIKE '%adv%'.advogado ou a renegociacoes, preservando a identidade original do titulo Chronos.30 dias > advogado > renegociacoes.cpf_cnpj, proposta e referencias operacionais compatíveis, para devolver resultado coerente ao usuario.cpf_cnpj do cliente pertence ao usuario logado segundo cobranca_atribuicao_cliente com status = 'ATIVO'.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.Travessia/Bralar de cada registro sem perder a legibilidade do dashboard.cobranca-hml antes de qualquer liberacao para producao.advogado sem contaminar 30 dias ou renegociacoes.Esta lista de requisitos funcionais passa a ser o contrato de capacidades da feature. Tudo o que precisaremos desenhar na arquitetura, quebrar em epicos/historias e implementar deve estar contido aqui. Se alguma capacidade relevante estiver ausente, ela nao existira formalmente no escopo ate ser adicionada ao PRD.
client_secret, token de acesso ou payloads sensiveis completos desnecessariamente.cpf_cnpj e referencias operacionais necessarias para cruzamento entre SQL Server, MySQL e Chronos.cpf_cnpj substituam ou colapsem parcelas distintas de um mesmo cliente.advogado e renegociacoes deve ser mutuamente exclusiva e reproduzivel, para que cards e grids nunca somem o mesmo titulo duas vezes.quebra, 30 dias ou renegociacao, e com base em qual criterio funcional.Travessia/Bralar deve ser consistente em todos os pontos do MVP onde o titulo for exibido ao usuario.Travessia/Bralar e de eventuais novos campos nao pode prejudicar a leitura operacional dos grids existentes.cobranca-hml antes de qualquer tentativa de publicacao em producao.Esses requisitos nao funcionais definem como a feature precisa se comportar em qualidade, seguranca e confiabilidade. Eles existem para garantir que a integracao Chronos seja util em operacao real, e nao apenas correta em um teste isolado.