chore: concluir Sprint 2 — Observabilidade e Logs

.cursor/rules/accessibility.mdc

@@ -0,0 +1,47 @@
+---
+alwaysApply: true
+description: "Regras oficiais de acessibilidade para UI do Vibe Intel."
+---
+
+# Accessibility — Vibe Intel
+
+A interface deve ser totalmente acessível seguindo estas regras:
+
+## Estrutura Semântica
+
+- Utilizar elementos HTML corretos: `button`, `nav`, `header`, etc.
+- Evitar divs sem função para elementos clicáveis.
+- Sempre usar `label` associado a inputs.
+
+## ARIA
+
+- Usar atributos ARIA apenas quando necessário.
+- Adicionar aria-label em ícones sem texto.
+- Garantir roles apropriadas para componentes complexos.
+
+## Navegação
+
+- Todos os elementos interativos devem ser acessíveis por teclado.
+- Foco visível em todos os elementos.
+- Não remover outline padrões sem alternativa acessível.
+
+## Imagens e Ícones
+
+- Imagens importantes devem ter alt significativo.
+- Ícones decorativos devem ter alt="" ou role="presentation".
+
+## Formulários
+
+- Inputs devem ter labels explícitas.
+- Erros devem ser anunciados e visualmente claros.
+- Inputs com validação devem comunicar estado (aria-invalid).
+
+## Contraste
+
+- Seguir WCAG AA no mínimo.
+- Garantir contraste suficiente entre texto e fundo.
+
+## Componentes
+
+- Modais devem bloquear fundo com ARIA modal.
+- Estruturas complexas (tabs, dropdowns, accordions) devem usar roles adequadas.

.cursor/rules/api-standards.mdc

@@ -0,0 +1,22 @@
+---
+alwaysApply: true
+description: "Regras de padronização da API (rotas, controllers, serviços)."
+---
+
+# Padrões de API — Vibe Intel
+
+Siga estes padrões ao criar endpoints:
+
+- Rotas devem seguir padrões REST.
+- Sempre usar:
+  - Controller → valida e chama service
+  - Service → lógica de negócio
+  - Schema Zod → input/output
+- Nenhuma lógica no controller.
+- Sempre retornar `sendSuccess` ou `sendError`.
+- Status codes corretos (ex: 200, 400, 401, 404, 500).
+- JSON sempre bem formatado.
+- Versionamento: `api/v1/`.
+- Integrações externas devem ser isoladas em camadas específicas.
+- Supabase Admin apenas em services.
+- Nada de rotas inline no arquivo principal.

.cursor/rules/api-versioning.mdc

@@ -0,0 +1,18 @@
+---
+alwaysApply: true
+description: "Regras oficiais para versionamento e evolução da API (REST v1/v2)."
+---
+
+# API Versioning — Vibe Intel
+
+Diretrizes obrigatórias:
+
+- Toda API deve estar dentro de uma versão: /api/v1/, /api/v2/…
+- Nunca modificar endpoints existentes sem criar nova versão.
+- Mudanças breaking exigem versão nova (v2).
+- Migrações de schema exigem comunicação explícita.
+- Services e controllers devem indicar claramente a versão.
+- Documentação deve ser atualizada sempre que nova versão surgir.
+- Rotas deprecated devem ter data de remoção.
+- Nunca expor múltiplas versões conflitantes no mesmo path.
+- Respostas e erros devem permanecer consistentes entre versões.

.cursor/rules/backend.mdc

@@ -0,0 +1,34 @@
+---
+alwaysApply: true
+description: "Regras oficiais para backend (API, Services, Controllers) do Vibe Intel."
+---
+
+# Regras de Backend — Vibe Intel
+
+Siga estas práticas ao gerar rotas, serviços, schemas ou controllers:
+
+- Controller nunca deve conter lógica de negócio.
+- Service deve conter 100% das regras de negócio.
+- Schema Zod obrigatório para entrada e saída.
+- Prisma: sempre utilizar cliente centralizado, nunca instanciar diretamente.
+- Supabase Admin: uso apenas em camada de serviço.
+- Nunca acessar req/res dentro do service.
+- Sempre retornar erros via `sendError`.
+- Sem retorno de erro cru.
+- Nunca expor stack trace.
+- Sempre tipar parâmetros e retornos do service.
+- Regras de segurança:
+  - RLS habilitado para todas as tabelas sensíveis.
+  - Nunca expor `service_role` no frontend.
+- Toda rota deve ter testes de integração.
+- Toda função de service deve ter testes unitários.
+- Estrutura obrigatória:
+  - /routes/[feature]/route.ts
+  - /controllers/[feature]Controller.ts
+  - /services/[feature]Service.ts
+  - /schemas/[feature]Schema.ts
+  - /tests/[feature].test.ts
+- Nunca criar endpoints sem autenticação se o caso exigir.
+- Usar ESM sempre.
+- Não permitir lógica duplicada entre serviços.
+- Lidar com falhas externas (ex: APIs) usando try/catch explícito.

.cursor/rules/ci-cd.mdc

@@ -0,0 +1,23 @@
+---
+alwaysApply: true
+description: "Regras de CI/CD (GitHub Actions + semantic-release)."
+---
+
+# CI/CD — Vibe Intel
+
+Regras obrigatórias:
+
+- Workflows devem incluir:
+  - lint
+  - test
+  - build
+  - typecheck
+- semantic-release é obrigatório para versionamento.
+- Nenhum merge sem testes passando.
+- Proibir commits direto na main.
+- Releases automáticos apenas via CI.
+- PRs precisam de:
+  - descrição clara
+  - checklist
+  - referência a issue
+- Nada de alterar arquivos gerados automaticamente no CI.

.cursor/rules/core-agent.mdc

@@ -0,0 +1,18 @@
+---
+alwaysApply: true
+description: "Regras específicas para o pacote core do Vibe Intel."
+---
+
+# Core Agent — Vibe Intel
+
+Regras para gerar código dentro do core:
+
+- Skills devem ficar isoladas e ter responsabilidade única.
+- Memory deve ser implementada como driver substituível.
+- Context loaders devem ser seguros e sem side effects.
+- Nunca executar comandos diretos sem sandbox.
+- Todo código deve ser totalmente tipado.
+- Executores devem ser puros e previsíveis.
+- Nenhum acesso direto ao sistema fora dos helpers.
+- Core não pode depender de UI ou API.
+- Resolver de habilidades deve seguir roteamento central.

.cursor/rules/deployment.mdc

@@ -0,0 +1,44 @@
+---
+alwaysApply: true
+description: "Regras de deploy e ambientes (CI/CD + produção) do Vibe Intel."
+---
+
+# Deployment — Vibe Intel
+
+Regras essenciais:
+
+## Ambientes
+
+- Nunca expor variáveis sensíveis no repositório.
+- Somente usar arquivos `.env.local` (não versionados).
+- Produção deve ser gerida via GitHub Actions secrets.
+
+## Next.js (UI)
+
+- Deploy apenas via Vercel.
+- Build deve ser livre de warnings.
+- Imagens devem usar domain whitelist.
+- Edge functions apenas quando necessário.
+
+## API
+
+- Deploy via Railway/Render (dependendo do ambiente final).
+- Banco de dados deve seguir migrações Prisma.
+- Nunca realizar deploy com migrações pendentes.
+
+## CI/CD
+
+- Testes → Lint → TypeCheck → Build → Release.
+- semantic-release controla versionamento.
+- Não permitir merges com falhas.
+
+## Supabase
+
+- Policies RLS devem ser aplicadas antes de deploy.
+- Storage deve ter regras de permissão revisadas.
+- Nunca expor service_role no cliente.
+
+## Logs
+
+- Produção usa logger JSON.
+- Nada de console.log na UI, API ou Core.

.cursor/rules/design-system.mdc

@@ -0,0 +1,59 @@
+---
+alwaysApply: true
+description: "Regras para o Design System oficial do Vibe Intel (cores, espaçamentos, tipografia, tokens)."
+---
+
+# Design System — Vibe Intel
+
+Todos os componentes devem seguir o design system oficial:
+
+## Tokens
+
+- Utilizar tokens de cor definidos no projeto (ex: primary, secondary, accent).
+- Utilizar spacing padronizado (ex: spacing-1..spacing-8).
+- Tipografia deve usar tokens oficiais (ex: heading-xl, body-md).
+
+## Tailwind v4
+
+- Sempre usar classes utilitárias do Tailwind.
+- Nenhum estilo inline exceto casos extremamente necessários.
+- Usar variantes de estado (hover, focus, active) sempre com consistência.
+
+## Cores
+
+- Somente utilizar cores definidas no tema.
+- Evitar valores hex diretamente no componente.
+- Cores devem ser usadas conforme significado (semantic colors).
+
+## Tipografia
+
+- Titles = classes de heading.
+- Texto = body classes.
+- Nada de usar h1/h2/h3 para estilização apenas.
+
+## Componentização
+
+- Criar componentes reutilizáveis e centralizados.
+- Componentes globais devem ir para /ui/src/components/global.
+- Não criar múltiplas versões do mesmo componente.
+- Utilizar atomic design (atoms → molecules → organisms).
+
+## Layout
+
+- Padding e margin sempre baseados nos tokens.
+- Grid e flex devem seguir padrões:
+  - gap obrigatório
+  - centralização consistente
+- Evitar aninhamento profundo de containers.
+
+## Animações
+
+- Usar framer-motion com presets.
+- Evitar animações pesadas.
+- Todas as animações devem ser opcionais e não bloquear interação.
+
+## Responsividade
+
+- Utilizar breakpoints do Tailwind.
+- Nunca esconder conteúdo importante em mobile.
+- Garantir legibilidade e espaçamento adequado.

.cursor/rules/documentation.mdc

@@ -0,0 +1,22 @@
+---
+alwaysApply: true
+description: "Padrões de documentação oficial do Vibe Intel."
+---
+
+Documentação — Vibe Intel
+=========================
+
+Regras:
+
+- Sempre gerar documentação junto com features complexas.
+- Usar markdown limpo e simples.
+- Todas as seções devem seguir:
+  - Overview
+  - Estrutura
+  - Fluxo
+  - Exemplo
+  - Notas
+- Tom técnico e neutro.
+- Links relativos, nunca URLs absolutas.
+- Atualizar architecture.md quando houver mudança estrutural.
+- Nenhuma documentação com texto redundante.

.cursor/rules/errors-logging.mdc

@@ -0,0 +1,18 @@
+---
+alwaysApply: true
+description: "Padrões de erros e logging em toda a plataforma Vibe Intel."
+---
+
+# Erros e Logging — Vibe Intel
+
+Regras:
+
+- Nunca usar console.log.
+- Usar logger centralizado.
+- Logs em JSON.
+- Sempre incluir contexto do domínio.
+- sendError deve ter mensagem clara e status correto.
+- Nunca vazar stack trace.
+- Erros externos devem ser embrulhados.
+- Logs não podem conter dados sensíveis.
+- Manter coerência entre API, Core e UI.

.cursor/rules/estilo-gustavo.mdc

@@ -0,0 +1,22 @@
+---
+alwaysApply: true
+description: "Estilo pessoal de desenvolvimento do Gustavo Marques."
+---
+
+# Estilo Gustavo — Regras de Escrita e Desenvolvimento
+
+Siga sempre o estilo de desenvolvimento preferido pelo Gustavo:
+
+- Código limpo, explícito e autoexplicativo.
+- Comentários somente quando agregarem contexto técnico real.
+- Preferir funções pequenas, puras e totalmente tipadas.
+- Evitar abstrações desnecessárias.
+- Clareza acima de “clever code”.
+- Se houver duas soluções possíveis, prefira a mais simples, estável e previsível.
+- Nenhum código duplicado.
+- Testes diretos, sem mocks excessivos.
+- Lógica deve ser dividida por domínio.
+- Sempre usar nomes claros (ex: `registerUser`, `fetchCotacoes`, `resolveCliente`).
+- Nunca gerar código ou arquivos não solicitados.
+- Respeitar a arquitetura definida em `.gpt/docs/architecture.md`.
+- Integrar sempre com blueprints e conventions.

.cursor/rules/file-structure.mdc

@@ -0,0 +1,43 @@
+---
+alwaysApply: true
+description: "Estrutura oficial de arquivos e pastas no Vibe Intel."
+---
+
+# Estrutura de Arquivos — Vibe Intel
+
+Obrigatório seguir a estrutura:
+
+/packages
+  /api
+    /routes
+    /controllers
+    /services
+    /schemas
+    /tests
+  /ui
+    /src/app
+    /components
+    /hooks
+    /services
+    /schemas
+    /store
+    /tests
+  /shared
+    /types
+    /utils
+    /schemas
+  /core
+    /agent
+    /skills
+    /memory
+    /context
+    /utils
+
+Regras:
+
+- Não adicionar arquivos fora dessas pastas sem permissão explícita.
+- Não criar novas pastas arbitrárias.
+- Cada domínio deve ter sua própria pasta.
+- Index.ts deve centralizar exports públicos.
+- Não misturar arquivos UI dentro do API e vice-versa.
+- Sempre nomear arquivos seguindo convenções oficiais.