Este projeto é um MVP funcional sendo elevado a produto profissional. O trabalho é de UI/UX e completude do produto: modernizar, reorganizar, tornar intuitivo e visualmente profissional — e garantir que tudo o que o serviço oferece esteja de fato exposto e acessível ao usuário.
O agente tem liberdade criativa para propor novos conteúdos, reorganizações, ideias de layout e melhorias que façam sentido para o produto — mesmo que não tenham sido explicitamente pedidas. Boas ideias devem ser implementadas, não só sugeridas.
Stack: Nuxt 4 + Tailwind CSS
- Nunca remover dados ou funcionalidades existentes. Reorganizar sim, excluir não.
- Nunca fazer tudo de uma vez. Cada página ou item de menu é uma demanda separada.
- Sempre perguntar antes de decisões estruturais grandes (ex: mudar roteamento, renomear arquivos críticos).
- Preservar a lógica de negócio. Só tocar em template e estilo, salvo instrução explícita.
Cada demanda segue este fluxo:
- Auditar o serviço — ler os READMEs relevantes para coletar contexto, decisões de arquitetura e convenções do projeto; verificar o que o service/API oferece de recursos e dados para essa feature; identificar o que já está exposto na UI e o que está faltando ou subutilizado
- Entender a página atual — quais dados ela exibe, qual ação o usuário realiza
- Planejar o layout — definir hierarquia visual, agrupamentos, fluxo de leitura; propor ideias novas quando agregar valor
- Identificar melhorias de UX — o que confunde? o que está escondido? o que falta feedback? o que o usuário esperaria ver e não vê? algum fluxo ou processo tem passos desnecessários ou uma ordem ruim?
- Implementar — aplicar Tailwind, componentizar onde faz sentido, implementar recursos faltantes identificados na auditoria
- Revisar — checar responsividade, estados vazios, loading, erro
Antes de implementar qualquer página, o agente deve:
- Ler os READMEs — do projeto raiz e de módulos relevantes, coletando contexto de arquitetura, decisões técnicas, convenções e qualquer informação que impacte a implementação
- Inspecionar o service correspondente e responder:
- Quais dados/recursos esse service disponibiliza?
- Todos eles estão sendo exibidos ou acessíveis na UI atual?
- Algum endpoint ou dado está sendo ignorado sem motivo?
- Há informações úteis ao usuário que estão só no backend?
Se encontrar lacunas, implementar — não apenas listar. O objetivo é que a UI reflita 100% do que o produto já é capaz de fazer.
Além da completude, avaliar também eficiência e estratégia: a API está estruturada da melhor forma para essa feature? Há queries desnecessárias, endpoints que poderiam ser consolidados, ou uma abordagem mais performática? Para ajustes simples, implementar diretamente. Para mudanças mais drásticas na arquitetura ou estratégia da API, apenas sugerir — descrever o problema, a melhoria proposta e o impacto esperado, sem implementar sem aprovação.
O agente não está limitado ao que já existe. É esperado e encorajado que:
- Proponha novos componentes que melhorem a experiência (filtros, buscas, ordenação, exportação, etc.)
- Sugira e implemente novas visualizações para dados existentes (gráficos, cards de resumo, timelines)
- Crie páginas de detalhe quando a listagem não for suficiente
- Introduza micro-interações e feedback visual que o MVP não tinha
- Reorganize a estrutura de navegação se não estiver intuitiva — isso inclui menu lateral, ordem de itens, agrupamentos, nomenclatura, breadcrumbs, links internos e o fluxo de transição entre páginas
- Identifique e melhore fluxos e processos ruins — se um processo exige passos desnecessários, é confuso ou pouco eficiente, reestruturar faz parte do trabalho. Não se limitar ao que existe: se o fluxo atual não serve bem ao usuário, propor e implementar um melhor
- Use modals, drawers, tabs, tooltips quando melhorarem o fluxo
Sobre pacotes e libs externas: o agente pode e deve instalar bibliotecas externas quando facilitarem o desenvolvimento ou elevarem a qualidade da UI — gráficos, árvores hierárquicas, calendários, editores rich text, drag-and-drop, animações, etc. Priorizar libs consolidadas, bem mantidas e compatíveis com Nuxt 4 + Tailwind. Registrar no README ou em comentário o motivo da adição quando não for óbvio.
Sobre dados: não inventar dados que não existem — tudo implementado deve ter fonte real ou ser criado no backend dentro do escopo abaixo.
Sobre o backend: o agente tem liberdade para implementar ou ajustar funções no core e na API quando julgar extremamente necessário para que a UI entregue a experiência correta. Isso inclui criar novos endpoints, adicionar campos a respostas existentes, ajustar regras de negócio simples ou expor dados que já existem mas não estão acessíveis. Toda alteração no backend deve ser sinalizada claramente — o que foi mudado, por quê, e o impacto esperado.
- Cada elemento na tela tem uma razão de existir
- Remover não é simplificar — é esconder. Reorganizar é simplificar
- Hierarquia visual clara: o olho do usuário sabe onde ir primeiro
- O usuário nunca deve precisar ler um manual
- Labels claros, ícones com texto de apoio quando necessário
- Substituir termos técnicos, siglas internas ou nomes de variáveis por linguagem clara e orientada ao usuário — o que faz sentido no backend não necessariamente faz sentido na tela
- Ações destrutivas sempre com confirmação
- Feedback imediato para toda ação (toast, loading state, erro inline)
- Consistência total: mesmos espaçamentos, mesmas cores, mesmos componentes
- Sem "gambiarras visuais" — se ficou estranho, refazer
- Mobile-first, mas desktop polido
Usar escala padrão do Tailwind com consistência:
- Espaço interno de cards:
p-4oup-6 - Gap entre seções:
gap-6ougap-8 - Margem de página:
px-4 md:px-8
- Título de página:
text-2xl font-semibold - Subtítulo / seção:
text-base font-medium text-gray-700 - Corpo / labels:
text-sm text-gray-600 - Dados em destaque:
text-lg font-semiboldoutext-2xl font-bold
Tema: Dark — fundo teal-escuro, acento verde-água
background: #0a1512 — fundo geral da aplicação
surface: #0f1c18 — sidebar, topbar, painéis
card: #132018 — cards, inputs, containers
active: #1a2e22 — item ativo no menu, row selecionada
hover: #162619 — hover de row ou item
elevated: #1e3326 — dropdowns, tooltips, modals
border: #1e3326 — cards e inputs em repouso
border-subtle: #162619 — divisores internos
border-hover: #2a4535 — hover state
border-focus: #2dd4aa — ring de foco
text-primary: #e8f0ee — títulos, dados
text-secondary: #8aada4 — corpo, labels
text-muted: #4d7268 — cabeçalho de tabela, hints
text-disabled: #2a4535 — placeholder, desabilitado
primary: #2dd4aa — botões CTA, links, ações (texto sobre ele: #0a1512)
success: #2dd4aa
warning: #c8a94a
danger: #c26a62
neutral: #0f1c18 a #e8f0ee
- Cards:
rounded-xl border border-[#1e3326] - Sombra leve:
shadow-sm - Sombra de foco/hover:
shadow-md - Inputs:
rounded-lg border border-[#1e3326] focus:ring-2 focus:ring-[#2dd4aa]
Primário: bg-[#2dd4aa] text-[#0a1512] rounded-lg px-4 py-2 font-medium hover:bg-[#26c49c]
Secundário: border border-[#1e3326] rounded-lg px-4 py-2 text-[#8aada4] hover:bg-[#162619]
Destrutivo: bg-[#c26a62] text-white ... (sempre com confirmação)
Ghost: bg-[#1a2e22] text-[#4d7268] hover:bg-[#162619]
bg-[#132018] rounded-xl border border-[#1e3326] shadow-sm p-6
- Header:
bg-[#0f1c18] text-xs font-medium text-[#4d7268] uppercase tracking-wide - Linhas:
border-t border-[#162619] hover:bg-[#162619] - Dados numéricos: alinhados à direita (
text-right)
- Label sempre acima do campo
- Erro inline abaixo do campo (
text-[#c26a62] text-sm) - Placeholder descritivo mas não substituto de label
- Campos obrigatórios marcados claramente
Toda listagem deve ter um estado vazio com:
- Ícone ilustrativo
- Mensagem explicativa
- Ação sugerida (botão ou link)
- Skeleton loaders para conteúdo de dados
- Spinner para ações pontuais (submit de formulário)
- Nunca deixar tela em branco durante carregamento
- Confirmações de ação (deletar, arquivar)
- Formulários curtos (até ~5 campos)
- Visualização rápida de detalhes sem perder contexto
- Alertas importantes
- Formulários longos ou complexos
- Fluxos de múltiplas etapas
- Detalhes completos de um item (ex: detalhe de pedido)
- Conteúdo relacionado que seria longo demais numa só tela
- Diferentes categorias do mesmo contexto (ex: Dados / Histórico / Configurações)
- Evitar scroll excessivo em páginas densas
- Formulários longos que podem ser divididos em grupos lógicos
- Fluxos de cadastro, configuração ou onboarding
- Processos onde a ordem das informações importa
- Qualquer formulário com mais de ~6 campos, avaliar se steps fazem sentido
Boas práticas de steps:
- Cada etapa deve ter um nome claro e curto (ex: "Dados Básicos", "Endereço", "Revisão")
- Mostrar sempre o progresso: indicador visual de etapa atual / total
- Permitir voltar à etapa anterior sem perder dados já preenchidos
- Última etapa deve ser uma tela de revisão antes de confirmar
- Validar cada etapa antes de avançar — nunca deixar o erro aparecer só no final
- Item ativo com destaque visual claro
- Ícone + label (nunca só ícone sem tooltip)
- Agrupamento lógico de itens relacionados
- Indicadores de notificação quando relevante
Toda página deve ter:
- Título claro da página
- Subtítulo ou breadcrumb (quando em subpágina)
- Ação principal alinhada à direita (ex: "Novo Item")
- Mobile: coluna única, navegação colapsada
- Tablet: 2 colunas onde fizer sentido
- Desktop: layout completo com sidebar
pages/
dashboard/
index.vue
[id].vue
components/
ui/
Button.vue
Card.vue
Modal.vue
Badge.vue
EmptyState.vue
[feature]/
FeatureCard.vue
FeatureForm.vue
- Componentes: PascalCase
- Arquivos de página: kebab-case ou index.vue
- Composables:
useprefix (useAuth,useFilters)
- Auditoria de serviço feita — todos os dados/recursos do service estão expostos na UI
- Layout responsivo (mobile, tablet, desktop)
- Estados: vazio, loading, erro, sucesso
- Feedback para todas as ações do usuário
- Hierarquia visual clara (o que é mais importante está em evidência)
- Nenhum dado ou funcionalidade removida
- Consistente com o design system definido acima
- Acessibilidade básica: contraste, foco visível, labels em inputs