Pular para o conteúdo
Histórico de chats
Novo chat
Imagens
ATUALIZADO
Confira planos e preços
Configurações
Ajuda

Receba respostas personalizadas para você

Entre para receber respostas com base em chats salvos, além de criar imagens e carregar arquivos.

Entrar
ChatGPT
Entrar
Cadastre-se gratuitamente

Esta é uma cópia de um chat compartilhado do ChatGPT. Isso não será adicionado à memória.

Denunciar conversa
hoje 10:45
Imagem carregada
Fase 1.2 — Protótipo Funcional Frontend da Plataforma de Recuperação de Crédito com Dados Mockados . Baseado na nossa ultima conversa da fase 1.1, vamos iniciar esta fase de desenvolvimento do frontend com dados mockados para entendermos todo o fluxo, regras de negócio, processos, design UX UI. Para te ajudar do design system, estou te enviando a paleta de cores e fontes padrão SICOOB. Acredito que a partir daqui, com estas informações, você deverá me dá um prompt para eu colocar no CLAUDE. Neste prompt,  me de no cabeçalho, qual modelo devo utilizar e intensidade, preciso que no prompt tenha a construção do CLAUDE.md 
Mostrar mais
Pensou por 1m 19s

Sim. A partir daqui eu mudaria oficialmente a ordem do projeto: primeiro vamos construir e validar o frontend funcional completo com dados mockados; somente depois congelaremos os fluxos e voltaremos ao backend e ao modelo de dados. Isso reduz bastante o risco de modelarmos banco/API e depois descobrirmos, pela experiência de uso, que o processo precisava ser diferente.

Para esta primeira execução no Claude Code, recomendo Claude Opus 5 com esforço High. A Anthropic posiciona o Opus 5 como modelo de alto nível para engenharia de software e tarefas agentic, com controle de esforço, o que combina com uma etapa que envolve arquitetura frontend, UX, regras de negócio e criação do CLAUDE.md. 
Anthropic
+1

Modelo: Claude Opus 5
Intensidade / Effort: High
Sessão: nova sessão do Claude Code
Objetivo: criar a fundação da Fase 1.2 + CLAUDE.md + frontend funcional mockado
Backend/Banco de dados: não desenvolver nesta fase

Abaixo está o prompt mestre que eu usaria. Você pode copiar inteiro e colar no Claude Code na raiz de uma pasta nova do projeto.

# MODELO RECOMENDADO
Claude Opus 5
Effort / Thinking: HIGH

# PROJETO
Plataforma de Gestão e Inteligência de Recuperação de Crédito

# FASE
Fase 1.2 — Protótipo Funcional Frontend da Plataforma de Recuperação de Crédito com Dados Mockados

# OBJETIVO DESTA FASE

Vamos construir o FRONTEND FUNCIONAL da Plataforma de Gestão e Inteligência de
Recuperação de Crédito antes da implementação do backend e do banco de dados.

A finalidade desta fase NÃO é apenas criar telas bonitas.

Precisamos criar um protótipo funcional suficientemente completo para validar:

- fluxos operacionais;
- experiência do usuário;
- regras de negócio;
- navegação;
- hierarquia das informações;
- fila de cobrança;
- visão 360º do cliente/caso;
- registros das ações de cobrança;
- promessas e negociações;
- pagamentos;
- réguas de cobrança;
- agentes de IA;
- importações;
- indicadores;
- perfis e permissões;
- processos humanos e automatizados.

Os dados serão totalmente MOCKADOS.

NÃO implementar backend.
NÃO implementar banco de dados.
NÃO criar API real.
NÃO integrar ElevenLabs.
NÃO integrar Net2Phone.
NÃO integrar WhatsApp.
NÃO executar chamadas reais.
NÃO usar dados reais de clientes.

As integrações externas devem ser apenas SIMULADAS visualmente.

A regra desta fase é:

FRONTEND → VALIDAÇÃO DOS FLUXOS → AJUSTES → CONGELAMENTO FUNCIONAL →
BACKEND/APIs → MODELO FÍSICO DO BANCO.

As decisões tomadas durante esta fase poderão provocar alterações no modelo de
dados preliminar criado na Fase 1.1.

Não tente preservar uma modelagem anterior se o frontend demonstrar que uma
estrutura diferente oferece um processo melhor.

==========================================================
1. PRIMEIRA AÇÃO OBRIGATÓRIA — CRIAR O CLAUDE.md
==========================================================

ANTES de escrever qualquer código da aplicação, crie na raiz do projeto:

CLAUDE.md

Esse arquivo será a memória técnica e funcional principal deste projeto para
todas as futuras sessões do Claude Code.

O CLAUDE.md deve conter, no mínimo, as seguintes seções:

# Plataforma de Gestão e Inteligência de Recuperação de Crédito

## 1. Visão do Produto

A aplicação não deve ser tratada como um simples sistema de cobrança.

Ela é uma:

"Plataforma de Gestão e Inteligência de Recuperação de Crédito"

O sistema deve permitir organizar, executar, acompanhar, automatizar e analisar
todo o processo de recuperação de crédito, combinando:

- operadores humanos;
- gestores;
- supervisores;
- jurídico;
- agências/cooperativas;
- auditoria;
- automações;
- agentes de inteligência artificial.

## 2. Momento atual do projeto

Registrar que estamos na:

Fase 1.2 — Protótipo Funcional Frontend com Dados Mockados.

O backend e o banco de dados ainda NÃO devem ser construídos.

O modelo de dados elaborado na Fase 1.1 é preliminar e poderá mudar em função
das descobertas desta fase.

## 3. Princípio arquitetural desta fase

O frontend deve funcionar através de:

mock JSON
        ↓
services/repositories mock
        ↓
estado da aplicação
        ↓
componentes/páginas

Os componentes NÃO devem importar diretamente arquivos JSON.

Deve existir uma camada intermediária de serviços/repositories para que,
posteriormente, seja possível substituir:

MockRepository

por:

ApiRepository

sem reescrever as telas.

Nunca espalhar regras de negócio dentro dos componentes visuais.

## 4. Domínio principal

O núcleo conceitual inicial é:

CLIENTE
   ↓
CASO DE COBRANÇA
   ↓
DÍVIDAS
   ↓
AÇÕES DE COBRANÇA

Um cliente poderá possuir diversas operações/dívidas.

A fila de cobrança deve ser prioritariamente orientada ao CASO/CLIENTE,
considerando o SALDO VENCIDO AGREGADO, e não simplesmente apresentar cada
parcela vencida como um item independente.

A interface deve permitir visualizar as dívidas/operações individuais dentro
do caso.

## 5. Fonte de dados futura

No sistema definitivo, dados de:

- clientes;
- dívidas/operações;
- parcelas;
- saldos;
- pagamentos;

serão recebidos principalmente através de importação de planilhas Excel.

Nesta fase, apenas simular essa experiência.

## 6. Processo principal

Registrar como fluxo macro:

Importação
→ processamento
→ cliente
→ dívidas
→ cálculo do saldo vencido agregado
→ classificação
→ aplicação das réguas
→ carteira/fila
→ ação de cobrança
→ registro da ação
→ acompanhamento
→ promessa/negociação
→ próxima ação
→ pagamento
→ encerramento ou continuidade.

## 7. Ação de cobrança como elemento central

Toda interação relevante com o cliente deverá gerar um REGISTRO DE AÇÃO DE
COBRANÇA.

Isso inclui ações realizadas por:

- atendente humano;
- telefone;
- WhatsApp;
- agente de IA por voz;
- agente de IA por mensagem;
- outros canais futuros.

Uma ação poderá possuir:

- data/hora;
- operador/agente;
- origem;
- canal;
- resultado;
- classificação;
- descrição;
- observações;
- transcrição;
- mensagens;
- promessa;
- valor prometido;
- vencimento da promessa;
- próxima ação;
- próxima data de contato.

## 8. Inteligência Artificial

A IA deve ser tratada como um ator formal da plataforma.

Existirão inicialmente dois grupos:

AGENTE DE IA POR VOZ

Arquitetura futura prevista:

Plataforma
→ ElevenLabs
→ agente de voz
→ infraestrutura SIP
→ Net2Phone
→ ligação ao cliente

As conversas deverão futuramente ser transcritas.

A transcrição deverá ficar associada ao registro da ação de cobrança.

AGENTE DE IA POR MENSAGEM

Contato através de WhatsApp.

As mensagens da conversa deverão futuramente ficar associadas ao registro da
ação de cobrança.

Nesta fase todas essas operações são SIMULADAS.

## 9. Réguas de cobrança

As réguas não são determinadas exclusivamente por quantidade de dias em atraso.

Elas poderão considerar combinações como:

- dias de atraso;
- saldo vencido agregado;
- carteira;
- produto;
- segmento;
- tipo de cliente;
- outros critérios futuros.

As regras devem ser CONFIGURÁVEIS.

Não espalhar condições hardcoded pela aplicação.

As faixas por valor já confirmadas incluem inicialmente:

Cobrança Vencida — Faixa 1
Saldo vencido agregado: até R$ 30.000,00
Tratamento: CCS

Cobrança Vencida — Faixa 2
Saldo vencido agregado: acima de R$ 30.000,00 até R$ 100.000,00
Tratamento: Equipe Interna

Outras faixas/regras não confirmadas não devem ser inventadas.

Criar a estrutura frontend e mock para permitir inclusão/configuração futura de
quantas regras forem necessárias.

## 10. Perfis

Prever inicialmente:

- Administrador;
- Gestor;
- Supervisor;
- Atendente / Negociador;
- Jurídico;
- Agência / Cooperativa;
- Auditor.

Agentes de IA também devem possuir identidade própria nas ações executadas,
embora não sejam usuários humanos convencionais.

## 11. Regra crítica desta fase

Ao identificar durante o desenvolvimento:

- conflito de regra;
- necessidade de entidade nova;
- campo ausente;
- fluxo inadequado;
- regra não definida;
- decisão que impactará backend;
- decisão que impactará banco;
- ambiguidade funcional;

NÃO inventar silenciosamente.

Registrar em documentação própria.

Criar:

docs/PHASE-1.2-DECISIONS.md
docs/BUSINESS-RULES.md
docs/BACKEND-DATA-MODEL-IMPACTS.md
docs/OPEN-QUESTIONS.md

Esses documentos deverão ser atualizados durante a evolução do protótipo.

## 12. Regra de desenvolvimento

Antes de implementar uma grande funcionalidade:

1. compreender o fluxo;
2. identificar regras;
3. criar mocks;
4. implementar experiência;
5. validar estados;
6. registrar impacto funcional/modelagem.

## 13. Restrições

Não construir backend.
Não construir banco.
Não criar autenticação real.
Não criar integração externa real.
Não armazenar credenciais.
Não inserir tokens/chaves.
Não usar CPF/CNPJ reais.
Não usar nomes reais de clientes.
Não incluir secrets no frontend.

Fim das instruções mínimas do CLAUDE.md.

Você poderá complementar o CLAUDE.md com padrões técnicos necessários ao
projeto, mas não poderá alterar as regras funcionais acima sem registrar a
alteração em PHASE-1.2-DECISIONS.md.

==========================================================
2. STACK DO FRONTEND
==========================================================

Utilize:

- React;
- TypeScript;
- Vite;
- React Router;
- Bootstrap 5 para grid/utilitários;
- CSS próprio para identidade visual;
- ícones consistentes;
- biblioteca de gráficos leve e adequada ao React;
- ESLint;
- Prettier.

Evite transformar visualmente a aplicação em um "Bootstrap padrão".

Bootstrap deve servir principalmente como fundação de layout/utilitários.

Os componentes visuais deverão possuir identidade própria.

Organize a aplicação para permitir futura substituição dos mocks por APIs.

Não introduza Redux ou arquitetura excessivamente complexa se não houver
necessidade.

==========================================================
3. DESIGN SYSTEM SICOOB
==========================================================

A identidade visual deve transmitir:

- instituição financeira;
- cooperativismo;
- segurança;
- seriedade;
- tecnologia;
- clareza;
- inteligência;
- alta densidade de informação sem poluição visual.

Utilizar como tokens principais:

Verde-petróleo
#003641

Verde-folha
#7DB61C

Turquesa
#00AE9D

Lima
#C9D200

Papel
#F4F7F5

Tinta
#0D1B1F

Criar tokens CSS, por exemplo:

--sicoob-petroleo
--sicoob-folha
--sicoob-turquesa
--sicoob-lima
--sicoob-papel
--sicoob-tinta

Além disso, criar escalas adequadas para:

- border;
- muted;
- backgrounds;
- hover;
- focus;
- success;
- warning;
- danger;
- info.

Não utilizar verde/lima indiscriminadamente.

Diretriz visual:

#003641:
estrutura principal, menu, títulos fortes, destaques institucionais.

#7DB61C:
ações positivas e CTA primário quando apropriado.

#00AE9D:
informações, indicadores, gráficos e elementos secundários.

#C9D200:
acentos e gráficos, utilizando com moderação.

#F4F7F5:
background principal da aplicação.

#0D1B1F:
textos principais.

Cards prioritariamente brancos.

Utilizar bordas suaves, sombras discretas e bastante respiro.

Evitar:
- gradientes exagerados;
- excesso de sombras;
- dashboards coloridos demais;
- aparência de template genérico;
- glassmorphism;
- efeitos futuristas desnecessários.

==========================================================
4. TIPOGRAFIA
==========================================================

Fonte corporativa preferencial:

Sicoob Sans

PORÉM:

somente utilizá-la se os arquivos oficiais/licenciados estiverem disponibilizados
no projeto.

Não buscar versões não oficiais.

Fallback:

Títulos, números e indicadores:
Manrope

Textos, tabelas e formulários:
Inter

Criar font stacks apropriadas.

Dar bastante atenção à legibilidade das tabelas, porque esta aplicação terá
grande densidade de dados.

==========================================================
5. EXPERIÊNCIA GERAL
==========================================================

Aplicação desktop-first, porém responsiva.

O principal ambiente de operação será tela de computador corporativo.

Priorizar resoluções de aproximadamente:

1366x768
1440x900
1920x1080

A experiência deve funcionar razoavelmente em tablet.

Utilizar:

Sidebar
Topbar
Breadcrumb
Área central de conteúdo

Sidebar recolhível.

Topbar contendo:

- breadcrumb/contexto;
- pesquisa quando aplicável;
- notificações simuladas;
- identificação do usuário;
- perfil;
- cooperativa/unidade quando aplicável.

Criar bom comportamento para:

- loading;
- empty state;
- erro;
- sem resultados;
- filtro vazio;
- conteúdo indisponível;
- acesso sem permissão.

==========================================================
6. MENU PRELIMINAR
==========================================================

Criar menu principal coerente com estes grupos:

VISÃO GERAL
Dashboard

COBRANÇA
Fila de Cobrança
Clientes / Casos
Ações de Cobrança
Promessas / Negociações

INTELIGÊNCIA E AUTOMAÇÃO
Réguas de Cobrança
Agentes de IA
Agenda / Execuções dos Agentes

DADOS
Importações
Pagamentos

GESTÃO
Equipes
Usuários
Perfis e Permissões

GOVERNANÇA
Auditoria

CONFIGURAÇÕES
Configurações Gerais

O menu deve respeitar permissões mockadas por perfil.

Não é necessário que todos os perfis enxerguem todos os itens.

==========================================================
7. LOGIN MOCK
==========================================================

Criar tela de login com identidade Sicoob.

Não implementar autenticação real.

Criar usuários mockados representando diferentes perfis.

Após login, permitir opcionalmente uma ferramenta DEV para trocar de persona,
facilitando a validação das permissões.

Exemplo:

Administrador
Gestor
Supervisor
Atendente
Jurídico
Agência
Auditor

Essa troca deve ser claramente identificada como recurso de protótipo.

==========================================================
8. DASHBOARD
==========================================================

Criar um dashboard executivo e operacional.

Exemplos de indicadores:

- saldo vencido total;
- quantidade de clientes em cobrança;
- quantidade de casos ativos;
- recuperado no período;
- promessas em aberto;
- promessas vencidas;
- taxa de recuperação;
- ações realizadas hoje;
- ações humanas;
- ações por IA;
- distribuição por faixa de atraso;
- distribuição por faixa de valor;
- distribuição por carteira/régua;
- evolução da recuperação;
- performance por equipe;
- performance por canal.

Criar dados mockados coerentes entre si.

Cards não devem ocupar espaço exagerado.

Usar gráficos somente quando agregarem informação.

==========================================================
9. FILA DE COBRANÇA — TELA CRÍTICA
==========================================================

Esta é uma das telas mais importantes do sistema.

A fila deve ser orientada ao CLIENTE/CASO.

Criar visual profissional de alta produtividade.

Mostrar, conforme espaço disponível:

- cliente;
- documento mascarado;
- PF/PJ;
- cooperativa/agência;
- saldo vencido agregado;
- dias de atraso;
- quantidade de operações;
- régua/faixa;
- carteira;
- prioridade;
- responsável;
- última ação;
- resultado da última ação;
- próxima ação;
- data da próxima ação;
- promessa ativa;
- status do caso.

Fornecer:

- pesquisa;
- filtros;
- ordenação;
- paginação;
- filtros rápidos;
- filtros avançados;
- opção de limpar filtros;
- totalizadores.

Exemplos de filtros:

Minha fila
Sem responsável
Com promessa
Promessa vencida
Sem contato
Contato hoje
Alta prioridade
IA agendada
Por régua
Por faixa
Por dias de atraso
Por valor
Por status

Criar ações rápidas.

A principal ação operacional será:

"Registrar ação"

Essa ação deverá abrir um MODAL funcional.

==========================================================
10. MODAL — REGISTRAR AÇÃO DE COBRANÇA
==========================================================

Criar uma experiência realmente utilizável.

Campos iniciais:

Cliente
Canal
Data/hora
Resultado do contato
Descrição/relato
Observações
Próxima ação
Data da próxima ação

Possibilidade de informar promessa:

Houve promessa?
Valor
Data prevista
Observação/condição

Exemplos de resultados:

Contato realizado
Sem contato
Telefone não atende
Número inválido
Recado
Negociação
Promessa de pagamento
Recusa de negociação
Solicitação de retorno
Encaminhamento
Outros

Esses valores devem vir de mock/configuração e não ficar pulverizados em
componentes.

Ao salvar:

- fechar modal;
- atualizar o estado local;
- adicionar evento à timeline;
- atualizar última ação;
- atualizar próxima ação;
- atualizar promessa se houver;
- refletir alterações na fila;
- mostrar toast de sucesso.

Isso precisa FUNCIONAR no protótipo.

==========================================================
11. VISÃO 360º — CLIENTE / CASO DE COBRANÇA
==========================================================

Ao clicar em um item da fila, abrir página detalhada.

Cabeçalho:

Nome
Documento mascarado
PF/PJ
Status
Régua
Carteira
Responsável
Prioridade

Resumo financeiro:

Saldo vencido agregado
Saldo a vencer quando aplicável
Dias de atraso
Quantidade de operações
Valor recuperado
Promessas abertas

Criar navegação por abas ou estrutura equivalente:

Visão Geral
Dívidas / Operações
Histórico / Timeline
Promessas
Pagamentos
Dados do Cliente
Agentes / Automações

A página deve permitir executar:

Registrar ação
Criar promessa
Alterar responsável
Agendar próxima ação

Tudo simulado no frontend.

==========================================================
12. TIMELINE
==========================================================

A timeline precisa ser um dos elementos centrais da visão 360º.

Unificar cronologicamente:

- ação humana;
- ligação;
- WhatsApp;
- agente de voz;
- agente de mensagem;
- promessa;
- quebra de promessa;
- pagamento;
- mudança de responsável;
- movimentação de carteira/régua;
- observação;
- alteração relevante.

Diferenciar visualmente:

Humano
IA
Sistema

sem transformar a tela em um carnaval de cores.

A timeline deverá suportar expansão de detalhes.

Para ligação de IA:

mostrar exemplo de:

Agente
Data/hora
Duração
Resultado
Resumo
Transcrição

A transcrição poderá ser expandida/recolhida.

Para WhatsApp:

mostrar mensagens mockadas dentro do registro.

==========================================================
13. DÍVIDAS / OPERAÇÕES
==========================================================

Apresentar todas as operações que formam o caso.

Mockar exemplos de:

- operação;
- contrato;
- produto;
- vencimento;
- dias de atraso;
- principal;
- encargos;
- saldo;
- status.

Mostrar claramente a diferença entre:

valor de uma operação

e

saldo vencido agregado do cliente/caso.

==========================================================
14. PROMESSAS / NEGOCIAÇÕES
==========================================================

Criar página e componentes para:

- promessa criada;
- promessa vigente;
- promessa próxima do vencimento;
- promessa vencida;
- promessa cumprida;
- promessa quebrada.

Cada promessa precisa ter vínculo visual com a ação que a originou.

Exibir:

Cliente
Valor
Data
Origem
Operador/agente
Situação
Pagamento relacionado

==========================================================
15. PAGAMENTOS
==========================================================

Criar tela de pagamentos mockados.

Os pagamentos futuramente serão originados das planilhas/importações.

Permitir visualizar:

cliente
operação
data
valor
origem
status de conciliação

Mostrar na visão do cliente os pagamentos relacionados.

==========================================================
16. IMPORTAÇÃO
==========================================================

Criar experiência visual de importação por Excel.

Nesta fase não precisa existir servidor.

Simular:

Selecionar arquivo
→ validar
→ pré-visualizar
→ apontar erros
→ mostrar novos registros
→ mostrar registros atualizados
→ mostrar inconsistências
→ confirmar processamento
→ mostrar resumo da importação.

Criar dados mockados para os estados desse fluxo.

Prever histórico de lotes/importações.

Exibir:

arquivo
data
usuário
registros
novos
atualizados
erros
status.

==========================================================
17. RÉGUAS DE COBRANÇA
==========================================================

Criar página especialmente importante para validação funcional.

Listar réguas.

Cada régua poderá conter condições combinadas.

Exemplo visual:

SE
saldo vencido >= X
E
saldo vencido <= Y
E
dias atraso >= Z

ENTÃO

carteira = ...
prioridade = ...
tratamento = ...
responsável/equipe = ...
estratégia = ...

Permitir visualizar/criar/editar regras no frontend mock.

Criar um construtor visual simples de condições.

Não construir um motor real de regras nesta fase.

Entretanto, os mocks devem demonstrar como ele funcionará.

==========================================================
18. AGENTES DE IA
==========================================================

Criar área:

Inteligência e Automação > Agentes de IA

Cards/listagem dos agentes.

Tipos:

Voz
WhatsApp

Campos:

Nome
Tipo
Status
Descrição
Objetivo
Réguas atendidas
Carteiras atendidas
Dias da semana
Horário permitido
Limite/configuração operacional simulada
Última execução
Próxima execução

Detalhe do agente de voz poderá mostrar:

Provider: ElevenLabs
Telefonia/SIP: Net2Phone

mas nenhuma integração deve ser realizada.

Criar:

Ativar
Desativar
Editar
Ver execuções

Tudo mockado.

==========================================================
19. AGENDA / EXECUÇÕES DE IA
==========================================================

Criar página para visualização das execuções automatizadas.

Exibir:

Agente
Cliente
Canal
Regra
Data/hora
Status
Resultado
Duração quando voz
Ação registrada

Possíveis estados simulados:

Agendado
Executando
Concluído
Sem contato
Falha
Cancelado

Permitir abrir execução e visualizar resultado.

==========================================================
20. USUÁRIOS, EQUIPES E PERMISSÕES
==========================================================

Criar telas suficientes para validar a administração.

Usuários
Equipes
Perfis

Não implementar autenticação real.

Criar matriz visual de permissões mockada.

Exemplos:

visualizar fila
registrar ação
editar promessa
visualizar dashboard
administrar régua
administrar agentes
visualizar auditoria
administrar usuários

==========================================================
21. AUDITORIA
==========================================================

Criar tela de auditoria mockada.

Eventos como:

login
alteração de responsável
alteração de régua
registro de ação
edição de promessa
ativação/desativação de agente
alteração administrativa

Exibir:

data/hora
ator
tipo
origem
entidade
descrição

==========================================================
22. MOCK DATA
==========================================================

Centralizar mocks.

Sugestão de organização:

src/
  mocks/
    users.json
    teams.json
    customers.json
    collectionCases.json
    debts.json
    payments.json
    collectionActions.json
    promises.json
    collectionRules.json
    agents.json
    agentRuns.json
    imports.json
    auditEvents.json

Não utilizar informações pessoais verdadeiras.

Criar cenário suficientemente rico para testar a aplicação.

Ter aproximadamente 25-40 clientes/casos diferentes.

Incluir situações diferentes:

sem contato
em negociação
com promessa
promessa cumprida
promessa quebrada
pagamento parcial
pagamento total
atraso curto
atraso longo
faixas diferentes
responsável humano
ação de IA
WhatsApp
voz
caso encerrado

Os valores apresentados em telas diferentes precisam ser coerentes.

Não gerar números aleatórios diferentes a cada renderização.

==========================================================
23. CAMADA DE SERVIÇOS
==========================================================

Mesmo com JSON, criar abstração semelhante a:

CustomerRepository
CollectionCaseRepository
CollectionActionRepository
PaymentRepository
PromiseRepository
RuleRepository
AgentRepository
ImportRepository

A UI não deverá saber se a informação veio de JSON ou API.

Idealmente:

interface CollectionCaseRepository

MockCollectionCaseRepository implements CollectionCaseRepository

Posteriormente poderemos criar:

ApiCollectionCaseRepository implements CollectionCaseRepository

sem reconstruir páginas.

==========================================================
24. ESTADO MUTÁVEL DO PROTÓTIPO
==========================================================

Precisamos conseguir utilizar a aplicação.

Por isso ações como:

registrar cobrança
criar promessa
trocar responsável
editar regra mock
ativar agente

devem atualizar o estado da aplicação.

Pode utilizar localStorage como persistência TEMPORÁRIA para o protótipo.

Criar mecanismo DEV para:

"Restaurar dados de demonstração"

para retornar ao estado inicial dos JSONs.

Não confundir esta persistência com arquitetura definitiva.

==========================================================
25. COMPONENTIZAÇÃO
==========================================================

Criar componentes reutilizáveis.

Exemplos conceituais:

AppShell
Sidebar
Topbar
PageHeader
Breadcrumb
MetricCard
StatusBadge
PriorityBadge
Money
DataTable
FilterBar
EmptyState
LoadingState
Timeline
TimelineItem
CollectionActionModal
CustomerSummary
DebtTable
PromiseCard
AgentCard
RuleBuilder
ConfirmDialog

Evitar componentes gigantes.

Evitar abstrações prematuras sem reutilização prática.

==========================================================
26. FORMATAÇÃO BRASILEIRA
==========================================================

Toda aplicação deverá utilizar PT-BR.

Moeda:

R$ 30.000,00

Datas:

09/09/2026

Data/hora:

09/09/2026 14:30

Decimal:
vírgula

Documento:
CPF/CNPJ mascarados nos mocks.

==========================================================
27. UX
==========================================================

O sistema será utilizado por pessoas que poderão executar dezenas ou centenas
de ações durante o dia.

Portanto priorizar:

- poucos cliques;
- leitura rápida;
- filtros persistentes;
- hierarquia visual;
- atalhos operacionais;
- feedback imediato;
- evitar modais desnecessários;
- ações primárias evidentes;
- informações financeiras legíveis;
- tabelas eficientes.

Registrar ação deve ser extremamente fácil.

O usuário deve conseguir navegar:

Dashboard
→ Fila
→ Cliente
→ Registrar ação
→ Definir próxima ação

sem se perder.

==========================================================
28. ACESSIBILIDADE
==========================================================

Garantir:

- contraste adequado;
- foco visível;
- navegação por teclado;
- labels;
- aria quando necessário;
- não depender exclusivamente de cor para status;
- botões com estados claros.

==========================================================
29. DOCUMENTAÇÃO DE DECISÕES
==========================================================

Durante a implementação, atualize:

docs/PHASE-1.2-DECISIONS.md

Formato recomendado:

## DEC-XXX — título

Data:
Contexto:
Problema:
Decisão:
Impacto no frontend:
Possível impacto no backend:
Possível impacto no banco:
Status: proposta | validada | descartada

Atualizar também:

docs/BACKEND-DATA-MODEL-IMPACTS.md

Sempre que descobrir uma informação que deverá alterar/revisar a Fase 1.1.

==========================================================
30. NÃO FAÇA
==========================================================

Não invente requisitos críticos silenciosamente.

Não criar backend "só para facilitar".

Não criar banco SQLite.

Não criar Prisma.

Não criar PostgreSQL.

Não criar endpoints.

Não colocar regras de negócio espalhadas em JSX.

Não criar arquivos gigantes.

Não implementar integração real.

Não colocar tokens.

Não incluir secrets.

Não utilizar dados pessoais reais.

Não utilizar lorem ipsum onde um dado de negócio fictício puder demonstrar
melhor a experiência.

Não construir simplesmente todas as telas sem pensar no fluxo entre elas.

==========================================================
31. PROCESSO DE EXECUÇÃO
==========================================================

Execute nesta ordem:

PASSO 1
Inspecione o diretório atual.

PASSO 2
Crie o CLAUDE.md.

PASSO 3
Crie os documentos:

docs/PHASE-1.2-DECISIONS.md
docs/BUSINESS-RULES.md
docs/BACKEND-DATA-MODEL-IMPACTS.md
docs/OPEN-QUESTIONS.md

PASSO 4
Defina arquitetura do frontend.

PASSO 5
Crie projeto React + TypeScript + Vite.

PASSO 6
Implemente Design System Sicoob.

PASSO 7
Crie AppShell, Sidebar, Topbar, rotas e autenticação mock.

PASSO 8
Crie estrutura dos mocks e repositories.

PASSO 9
Implemente primeiro o fluxo vertical crítico:

Login
→ Dashboard
→ Fila de Cobrança
→ Cliente 360
→ Registrar Ação
→ Timeline
→ Próxima Ação/Promessa

Esse fluxo deverá estar FUNCIONAL antes de ampliar para telas secundárias.

PASSO 10
Depois implemente:

Réguas
Agentes de IA
Execuções
Importações
Pagamentos
Usuários
Equipes
Permissões
Auditoria

PASSO 11
Execute:

lint
typecheck
build

PASSO 12
Corrija os problemas encontrados.

==========================================================
32. RESULTADO ESPERADO
==========================================================

Quando terminar esta execução, eu quero conseguir iniciar a aplicação e
navegar pelo protótipo.

Ela deve parecer uma aplicação corporativa real, e não um conjunto de
wireframes.

Preciso conseguir testar visualmente e funcionalmente:

- como o atendente trabalha;
- como o gestor acompanha;
- como o cliente/caso é apresentado;
- como uma cobrança é registrada;
- como uma promessa é criada;
- como o histórico evolui;
- como uma régua aparece;
- como agentes de IA são administrados;
- como as execuções dos agentes aparecem;
- como importações serão tratadas;
- como informações financeiras são apresentadas.

O objetivo principal é DESCOBRIR problemas funcionais agora, antes da
implementação do backend e banco.

==========================================================
33. COMPORTAMENTO ESPERADO DO CLAUDE CODE
==========================================================

Você tem autonomia para implementar a estrutura e corrigir problemas técnicos.

Entretanto, se durante o desenvolvimento encontrar uma decisão de NEGÓCIO que
possa alterar significativamente o fluxo da plataforma:

não invente uma solução definitiva.

Implemente a alternativa mais neutra quando necessário para o protótipo e
registre a questão em:

docs/OPEN-QUESTIONS.md

Ao final, apresente um relatório contendo:

1. estrutura criada;
2. páginas implementadas;
3. fluxos funcionais;
4. mocks criados;
5. decisões tomadas;
6. decisões de negócio pendentes;
7. impactos identificados na futura API/backend;
8. impactos identificados no modelo de dados da Fase 1.1;
9. resultado de lint;
10. resultado de typecheck;
11. resultado de build;
12. instruções para executar localmente.

IMPORTANTE:

Não me entregue somente planejamento.

Após criar CLAUDE.md e documentação inicial, implemente efetivamente o
frontend.

Comece agora.

Há um ponto importante nessa estratégia: eu fiz o prompt obrigar o Claude a criar uma camada de repositories entre os JSONs e as telas. Isso evita um erro comum em protótipos: componentes fazendo import customers.json por toda parte. Quando chegarmos ao backend, a ideia será trocar algo como MockCollectionCaseRepository por ApiCollectionCaseRepository, preservando grande parte do frontend.

Também inseri três documentos que considero fundamentais para este projeto: PHASE-1.2-DECISIONS.md, BACKEND-DATA-MODEL-IMPACTS.md e OPEN-QUESTIONS.md. É justamente aí que vamos registrar tudo que o protótipo nos fizer descobrir. Assim, a Fase 1.1 deixa de ser uma camisa de força: ela vira nosso modelo preliminar, que será refinado pela experiência real do frontend.

E concordo com uma decisão adicional que coloquei no prompt: não mandaria o Claude tentar aperfeiçoar todas as telas simultaneamente. Primeiro queremos deixar impecável o fluxo operacional central:

Login → Dashboard → Fila de Cobrança → Cliente 360º → Registrar Ação → Timeline → Promessa/Próxima Ação.

Esse é o coração da plataforma. Depois que o Claude executar esse prompt e você abrir a aplicação no navegador, pode me mandar prints das telas ou o relatório que o Claude gerar. Aí faremos a validação da Fase 1.2 tela por tela e eu vou lhe passando os próximos prompts de evolução, sem ainda entrarmos no backend.

Fontes
ChatGPT é uma IA e pode cometer erros.
