commit 45cd8d2f0353a381f89fd43c9cfdc0df832d8446 Author: Tiago Date: Sun Oct 4 10:42:23 2026 -0300 Initial SeConectai briefing system diff --git a/.env.example b/.env.example new file mode 100644 index 0000000..2ea0fbc --- /dev/null +++ b/.env.example @@ -0,0 +1,25 @@ +DATABASE_URL="postgresql://briefing:briefing@db:5432/briefing?schema=public" +POSTGRES_DB="briefing" +POSTGRES_USER="briefing" +POSTGRES_PASSWORD="" +AUTH_SECRET="" +APP_URL="http://localhost:3000" +APP_DOMAIN="briefing.example.com" +LETSENCRYPT_EMAIL="admin@example.com" +CPF_ENC_KEY="" +CPF_HASH_KEY="" +SMTP_HOST="" +SMTP_PORT="587" +SMTP_USER="" +SMTP_PASS="" +SMTP_FROM="" +ADMIN_EMAIL="" +ADMIN_INITIAL_PASSWORD="" +EVOLUTION_API_URL="" +EVOLUTION_API_KEY="" +EVOLUTION_API_INSTANCE="" +ADMIN_WHATSAPP="" +UPLOAD_DIR="/app/storage/uploads" +UPLOAD_MAX_MB="25" +BACKUP_DIR="./backups" +BACKUP_RETENTION_DAYS="14" diff --git a/.eslintrc.json b/.eslintrc.json new file mode 100644 index 0000000..957cd15 --- /dev/null +++ b/.eslintrc.json @@ -0,0 +1,3 @@ +{ + "extends": ["next/core-web-vitals"] +} diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..3c5aa94 --- /dev/null +++ b/.gitignore @@ -0,0 +1,9 @@ +node_modules +.next +out +dist +.env +.env*.local +*.log +storage/uploads +coverage diff --git a/Caddyfile b/Caddyfile new file mode 100644 index 0000000..c99bfe0 --- /dev/null +++ b/Caddyfile @@ -0,0 +1,8 @@ +{ + email {$LETSENCRYPT_EMAIL} +} + +{$APP_DOMAIN} { + encode gzip zstd + reverse_proxy app:3000 +} diff --git a/Conhecimento/AGENTS.md b/Conhecimento/AGENTS.md new file mode 100644 index 0000000..9c58f37 --- /dev/null +++ b/Conhecimento/AGENTS.md @@ -0,0 +1,260 @@ +# Vibe Frontend Agents — Orquestrador Principal + +Este arquivo é a fonte central de regras para qualquer IA/agente que trabalhe neste projeto. +Ele deve ser lido **antes de qualquer alteração**. Os arquivos em `agents/`, `skills/`, `prompts/` +e `checklists/` complementam estas instruções e devem ser carregados conforme a tarefa. + +--- + +## 1. Missão + +Melhorar ou construir interfaces sem comprometer regras de negócio, integrações, autenticação, +segurança, dados, contratos de API ou estabilidade do sistema. + +O objetivo não é apenas “deixar bonito”. O objetivo é produzir uma interface: +- clara; +- coerente; +- acessível; +- responsiva; +- rápida; +- reutilizável; +- testável; +- previsível; +- simples de manter; +- segura para evoluir. + +--- + +## 2. Regra de ouro: analisar antes de modificar + +Antes de editar qualquer arquivo de um projeto existente: + +1. Identifique a stack, framework, gerenciador de pacotes e processo de build. +2. Mapeie a estrutura de pastas e responsabilidades principais. +3. Identifique rotas, layouts, componentes, hooks/composables, stores, serviços e estilos. +4. Localize autenticação, autorização, chamadas de API, contratos de dados e integrações. +5. Verifique se existe design system ou biblioteca de componentes já adotada. +6. Verifique lint, typecheck, testes, Storybook, E2E e comandos de validação. +7. Entenda exatamente o escopo solicitado pelo usuário. +8. Determine quais agentes especializados realmente precisam participar. +9. Só então altere o código. + +Nunca reescreva grandes partes do projeto apenas porque uma solução diferente parece mais elegante. + +--- + +## 3. Proteção obrigatória do sistema + +Quando a solicitação for de frontend, UI, UX, responsividade, acessibilidade, SEO ou performance, +NÃO altere os itens abaixo sem necessidade técnica real e autorização explícita: + +- banco de dados; +- migrations; +- seeds; +- entidades persistidas; +- schemas de banco; +- contratos públicos de API; +- endpoints; +- controllers do backend; +- services de regra de negócio; +- autenticação; +- autorização; +- roles e permissões; +- tokens, sessões e cookies de segurança; +- webhooks; +- filas; +- workers; +- integrações externas; +- configuração de infraestrutura; +- deploy; +- Docker/Compose/Kubernetes; +- DNS; +- variáveis de ambiente reais; +- segredos; +- CI/CD. + +### Exceção + +Se a alteração de frontend exigir mudança em uma dessas áreas: +1. não faça a alteração silenciosamente; +2. explique a dependência; +3. proponha a menor mudança possível; +4. preserve compatibilidade retroativa quando viável; +5. só implemente se a tarefa autorizar. + +--- + +## 4. Arquivos que devem ser carregados por tipo de tarefa + +### Toda tarefa em projeto existente +Leia primeiro: +- `agents/00-project-analyzer.md` +- `agents/01-codebase-guardian.md` + +### UI/UX ou melhoria visual +Leia: +- `agents/02-ui-ux.md` +- `agents/03-design-system.md` +- `agents/04-frontend.md` + +### Formulários, cadastro, edição, filtros ou autenticação +Leia também: +- `agents/05-forms.md` + +### Tabelas, painéis, ERP, CRM, SaaS administrativo +Leia também: +- `agents/06-dashboard.md` + +### Site institucional, landing page, página comercial +Leia também: +- `agents/07-landing-page.md` +- `agents/10-seo.md` + +### Mobile/responsividade +Leia: +- `agents/08-responsive.md` + +### Acessibilidade +Leia: +- `agents/09-accessibility.md` + +### Performance +Leia: +- `agents/11-performance.md` + +### Revisão final +Leia sempre ao finalizar alteração relevante: +- `agents/12-visual-qa.md` +- `agents/13-regression-check.md` + +--- + +## 5. Pipeline padrão + +### Fase A — Descoberta +1. Ler este `AGENTS.md`. +2. Ler `00-project-analyzer.md`. +3. Ler `01-codebase-guardian.md`. +4. Inspecionar o projeto. +5. Registrar stack, arquitetura, riscos e escopo. + +### Fase B — Planejamento +1. Classificar a tarefa. +2. Selecionar somente os agentes necessários. +3. Identificar componentes afetados. +4. Identificar dependências e riscos de regressão. +5. Elaborar um plano mínimo de mudança. + +### Fase C — Implementação +1. Reutilizar padrões existentes. +2. Alterar o menor número razoável de arquivos. +3. Preservar contratos existentes. +4. Tratar estados de UI. +5. Evitar duplicação. +6. Não adicionar dependências sem justificativa. + +### Fase D — Validação +1. Build. +2. Typecheck. +3. Lint. +4. Testes disponíveis. +5. Navegação principal. +6. Mobile e desktop. +7. Estados loading/erro/vazio/sucesso. +8. Acessibilidade básica. +9. Console sem erros relevantes. +10. Revisão visual. +11. Checagem de regressão. + +### Fase E — Entrega +Explique: +- o que foi alterado; +- por que foi alterado; +- arquivos principais envolvidos; +- validações executadas; +- riscos ou limitações restantes; +- sugestões opcionais, sem misturá-las ao escopo concluído. + +--- + +## 6. Seleção inteligente de agentes + +Não execute todos os especialistas mecanicamente. + +Exemplos: +- Ajuste de espaçamento em um componente: analyzer + guardian + frontend + visual QA. +- Página de cadastro: analyzer + guardian + UI/UX + design system + frontend + forms + responsive + accessibility + regression. +- Dashboard: analyzer + guardian + UI/UX + design system + frontend + dashboard + responsive + accessibility + performance + regression. +- Landing page: analyzer + guardian + UI/UX + design system + frontend + landing page + responsive + accessibility + SEO + performance + visual QA. + +--- + +## 7. Regras de implementação + +### Preserve o que já existe +- Não renomeie arquivos ou componentes sem benefício claro. +- Não troque framework, biblioteca ou padrão arquitetural sem solicitação. +- Não converta JS para TS, CSS para Tailwind, Redux para Zustand etc. como efeito colateral. +- Não faça “limpeza geral” fora do escopo. + +### Dependências +Antes de instalar uma dependência: +1. verifique se o projeto já oferece solução equivalente; +2. verifique se a plataforma/framework tem recurso nativo; +3. avalie custo de bundle e manutenção; +4. justifique a instalação. + +### Componentização +Crie componente quando houver pelo menos um destes motivos: +- reutilização real; +- responsabilidade visual/funcional clara; +- redução de complexidade; +- necessidade de teste isolado; +- padronização de comportamento. + +Não crie componentes microscópicos sem ganho prático. + +--- + +## 8. Estados obrigatórios de interface + +Sempre que aplicável, considere: +- inicial; +- carregando; +- sucesso; +- vazio; +- erro; +- sem permissão; +- indisponível; +- ação em andamento; +- ação concluída; +- confirmação antes de ação destrutiva. + +Nunca exiba uma tela quebrada apenas porque uma API retornou array vazio ou falhou. + +--- + +## 9. Regras de dados + +- Não invente métricas reais. +- Não fabrique dados de produção. +- Não altere valores financeiros, permissões ou status de negócio para fins visuais. +- Diferencie mock, fixture e dado real. +- Respeite locale, moeda, fuso e formatação existente. +- Não exponha secrets ou tokens no frontend. + +--- + +## 10. Critério de pronto + +Uma alteração só pode ser considerada concluída quando: +- atende exatamente ao pedido; +- funcionalidade existente continua funcionando; +- não alterou regra de negócio indevidamente; +- desktop e mobile foram considerados; +- estados relevantes foram tratados; +- acessibilidade básica foi verificada; +- build/typecheck/lint/testes aplicáveis passam, ou falhas preexistentes foram documentadas; +- não existem erros novos óbvios no console; +- o código segue padrões do projeto; +- o resultado é sustentável para manutenção. diff --git a/Conhecimento/README.md b/Conhecimento/README.md new file mode 100644 index 0000000..cec5099 --- /dev/null +++ b/Conhecimento/README.md @@ -0,0 +1,77 @@ +# Vibe Frontend Agents v2 + +Pacote de instruções para orientar ferramentas de Vibe Coding e agentes de IA em projetos frontend. +A versão 2 transforma o `AGENTS.md` em um **orquestrador central**, separa responsabilidades e adiciona proteção contra regressões. + +## Estrutura + +```text +AGENTS.md Orquestrador e regras globais +agents/ Papéis especializados +skills/ Guias técnicos reutilizáveis +prompts/ Entradas prontas para tarefas comuns +checklists/ Conferência antes e depois de alterações +``` + +## Como instalar + +Copie `AGENTS.md`, `agents/`, `skills/`, `prompts/` e `checklists/` para a raiz do projeto. + +> Importante: o suporte automático a `AGENTS.md` varia entre ferramentas. Quando sua ferramenta não carrega arquivos auxiliares automaticamente, peça explicitamente para ela ler o arquivo principal e os agentes indicados pelo orquestrador. + +## Fluxo recomendado — projeto existente + +1. `prompts/auditar-projeto.md` +2. revisar diagnóstico quando a tarefa exigir auditoria formal; +3. `prompts/melhorar-frontend.md` ou prompt especializado; +4. implementar; +5. `prompts/revisao-final.md`. + +## Fluxo recomendado — dashboard + +Use `prompts/criar-dashboard.md`. + +## Fluxo recomendado — landing page + +Use `prompts/criar-site.md`. + +## Fluxo recomendado — correção mobile + +Use `prompts/fix-mobile.md`. + +## Filosofia + +O pacote prioriza: +- análise antes de edição; +- menor mudança segura; +- preservação do backend e regras de negócio; +- consistência visual; +- estados completos de interface; +- responsividade; +- acessibilidade; +- validação e prevenção de regressões. + +## Ordem dos agentes + +```text +00 Project Analyzer +01 Codebase Guardian +02 UI/UX +03 Design System +04 Frontend +05 Forms +06 Dashboard +07 Landing Page +08 Responsive +09 Accessibility +10 SEO +11 Performance +12 Visual QA +13 Regression Check +``` + +Nem todos são usados em toda tarefa. O `AGENTS.md` explica a seleção. + +## Compatibilidade + +O conteúdo foi escrito de forma agnóstica a editor/agente. Pode ser usado como contexto em ferramentas que respeitam arquivos de instrução ou manualmente através dos prompts. diff --git a/Conhecimento/agents/00-project-analyzer.md b/Conhecimento/agents/00-project-analyzer.md new file mode 100644 index 0000000..552d01d --- /dev/null +++ b/Conhecimento/agents/00-project-analyzer.md @@ -0,0 +1,65 @@ +# Agente 00 — Project Analyzer + +## Papel +É o primeiro especialista de qualquer projeto existente. Sua função é compreender o sistema sem alterar código. + +## Objetivo +Criar um mapa confiável do projeto para evitar mudanças cegas, retrabalho e regressões. + +## O que deve identificar + +### Stack +- framework principal; +- versão aproximada quando disponível; +- linguagem; +- bundler; +- gerenciador de pacotes; +- biblioteca de componentes; +- solução de estilos; +- gerenciamento de estado; +- roteamento; +- cliente HTTP; +- validação de formulários; +- internacionalização; +- testes; +- lint e formatter. + +### Arquitetura +- ponto de entrada; +- layouts; +- rotas; +- páginas/views; +- componentes compartilhados; +- hooks/composables; +- stores/context; +- services/API; +- tipos/interfaces; +- assets; +- estilos globais; +- configuração. + +### Fluxos críticos +Mapear quando possível: +- login/logout; +- recuperação de sessão; +- permissões; +- criação/edição/exclusão; +- upload; +- filtros e busca; +- pagamentos; +- integrações críticas. + +## Saída esperada +Antes de mudanças relevantes, tenha mentalmente ou registre: +1. Stack detectada. +2. Arquivos mais importantes. +3. Padrões existentes. +4. Áreas sensíveis. +5. Arquivos provavelmente afetados pela tarefa. +6. Riscos. +7. Validações possíveis. + +## Proibições +- Não implementar durante a análise inicial. +- Não concluir que algo “não existe” sem procurar adequadamente. +- Não sugerir reescrita completa por preferência pessoal. diff --git a/Conhecimento/agents/01-codebase-guardian.md b/Conhecimento/agents/01-codebase-guardian.md new file mode 100644 index 0000000..a26f9a4 --- /dev/null +++ b/Conhecimento/agents/01-codebase-guardian.md @@ -0,0 +1,46 @@ +# Agente 01 — Codebase Guardian + +## Papel +Proteger comportamento existente, contratos e regras de negócio durante alterações de frontend. + +## Responsabilidades + +### Delimitar o escopo +Classifique cada alteração como: +- necessária para o pedido; +- necessária como dependência direta; +- melhoria opcional; +- fora de escopo. + +Implemente apenas as duas primeiras categorias, salvo pedido explícito. + +### Proteger contratos +Verifique antes de alterar: +- nomes de campos enviados/recebidos; +- formatos de payload; +- query parameters; +- headers; +- status esperados; +- tipos públicos; +- eventos emitidos; +- nomes de storage/cookies; +- permissões. + +### Segurança +Nunca: +- mover segredo para código cliente; +- logar token sensível; +- remover validação de permissão; +- esconder ação proibida apenas visualmente quando o backend exige controle; +- relaxar CORS/CSP/autenticação para “fazer funcionar”. + +### Compatibilidade +Prefira alterações aditivas a mudanças quebradoras. + +## Checklist antes de salvar mudança +- Esta edição muda comportamento de negócio? +- Muda contrato de API? +- Muda autenticação ou autorização? +- Remove alguma capacidade existente? +- Afeta fluxo que não foi solicitado? +- É possível resolver de maneira menor? diff --git a/Conhecimento/agents/02-ui-ux.md b/Conhecimento/agents/02-ui-ux.md new file mode 100644 index 0000000..661b958 --- /dev/null +++ b/Conhecimento/agents/02-ui-ux.md @@ -0,0 +1,51 @@ +# Agente 02 — UI/UX + +## Papel +Projetar experiências claras e eficientes antes de pensar apenas em aparência. + +## Objetivos +- reduzir esforço cognitivo; +- deixar hierarquia visual evidente; +- facilitar descoberta de ações; +- reduzir erros; +- manter consistência; +- priorizar a tarefa principal do usuário. + +## Análise de tela +Avalie: +1. Qual é a finalidade da tela? +2. Qual ação principal deve se destacar? +3. Quais informações são primárias, secundárias e auxiliares? +4. Existe excesso de opções competindo? +5. Usuário entende estado atual? +6. Feedback após ação é claro? +7. Mensagens de erro ajudam a corrigir? +8. Há ações destrutivas sem confirmação? +9. O conteúdo segue ordem lógica? +10. Existe dependência desnecessária de cor ou ícone? + +## Hierarquia +Use com intenção: +- títulos; +- subtítulos; +- agrupamento; +- whitespace; +- contraste; +- alinhamento; +- tamanho; +- posição; +- peso tipográfico. + +## Microcopy +Textos de botões e mensagens devem indicar ação concreta. +Prefira “Salvar alterações” a “OK”, “Excluir cliente” a “Confirmar” quando isso reduz ambiguidade. + +## Feedback +Toda ação assíncrona deve indicar progresso e desfecho. +Evite clique sem resposta visual. + +## Ações destrutivas +- diferenciar visualmente; +- confirmar quando consequência é relevante; +- explicar objeto afetado; +- evitar confirmação genérica quando contexto importa. diff --git a/Conhecimento/agents/03-design-system.md b/Conhecimento/agents/03-design-system.md new file mode 100644 index 0000000..839ef35 --- /dev/null +++ b/Conhecimento/agents/03-design-system.md @@ -0,0 +1,52 @@ +# Agente 03 — Design System + +## Papel +Garantir consistência de tokens, componentes e padrões visuais. + +## Prioridade +1. Reutilizar design system existente. +2. Estender de forma compatível. +3. Criar novo sistema somente se não houver base adequada. + +## Tokens mínimos +Quando o projeto comportar tokens, organize: +- cores semânticas; +- tipografia; +- espaçamento; +- raios; +- bordas; +- sombras; +- breakpoints; +- z-index; +- duração/easing de animação. + +Evite valores arbitrários repetidos. + +## Componentes básicos esperados +Conforme o tipo de projeto: +- Button; +- Input; +- Select; +- Textarea; +- Checkbox/Radio/Switch; +- FormField; +- Alert; +- Badge; +- Modal/Dialog; +- Drawer; +- Tooltip; +- Dropdown; +- Tabs; +- Card; +- Table; +- Pagination; +- Skeleton; +- EmptyState; +- Toast. + +## Variantes +Variantes devem representar intenção real, como primary, secondary, danger, ghost, success. +Não crie dezenas de variantes que só encapsulam diferenças arbitrárias. + +## Regra de consistência +Dois elementos com mesma função devem se comportar e parecer relacionados. diff --git a/Conhecimento/agents/04-frontend.md b/Conhecimento/agents/04-frontend.md new file mode 100644 index 0000000..8b3f128 --- /dev/null +++ b/Conhecimento/agents/04-frontend.md @@ -0,0 +1,42 @@ +# Agente 04 — Frontend Implementation + +## Papel +Transformar decisões de UX e design em código confiável e sustentável. + +## Princípios +- seguir padrões do repositório; +- favorecer legibilidade; +- manter componentes focados; +- minimizar efeitos colaterais; +- evitar estado duplicado; +- tratar concorrência e loading quando aplicável; +- não esconder falhas silenciosamente. + +## Estado +Antes de criar estado local pergunte: +- isso pode ser derivado de props/dados existentes? +- pertence realmente a este componente? +- precisa sobreviver a navegação? +- já existe store/context para isso? + +## Assíncrono +Considere: +- cancelamento/obsolescência de requisições; +- cliques repetidos; +- botão desabilitado durante submissão; +- erro recuperável; +- retry quando apropriado; +- atualização otimista somente quando segura. + +## Componentes +Separe lógica e apresentação quando isso reduzir complexidade, não como dogma. + +## Tipos +Não use `any` indiscriminadamente quando o projeto é TypeScript. +Preserve tipos de contratos externos. + +## CSS +- respeitar estratégia do projeto; +- evitar!important salvo necessidade real; +- evitar seletores frágeis; +- não duplicar regra já disponível por token/utilitário. diff --git a/Conhecimento/agents/05-forms.md b/Conhecimento/agents/05-forms.md new file mode 100644 index 0000000..a66d5a3 --- /dev/null +++ b/Conhecimento/agents/05-forms.md @@ -0,0 +1,45 @@ +# Agente 05 — Forms & Validation + +## Papel +Especialista em formulários, validação e entrada de dados. + +## Objetivos +- reduzir erro de preenchimento; +- preservar dados do usuário; +- tornar validações compreensíveis; +- impedir envio duplicado; +- suportar teclado e mobile; +- manter coerência com regras do backend. + +## Cada campo deve considerar +- label visível; +- descrição quando necessária; +- placeholder apenas como exemplo, nunca substituto de label; +- required/optional claro; +- tipo de input adequado; +- autocomplete adequado; +- máscara sem destruir valor real; +- limite/tamanho quando aplicável; +- mensagem de erro específica; +- vínculo acessível entre erro e campo. + +## Validação +- validação cliente melhora UX, mas não substitui backend; +- mensagens devem dizer como corrigir; +- não apagar dados após erro; +- preferir validação no momento adequado, evitando agressividade a cada tecla quando não necessário. + +## Submissão +Durante envio: +- impedir duplo submit; +- mostrar estado em andamento; +- manter contexto; +- tratar sucesso; +- tratar erro global; +- rolar/focar primeiro erro quando útil. + +## Edição +Não sobrescrever valores não alterados sem necessidade. + +## Ações perigosas +Mudança de senha, exclusão, pagamento e dados sensíveis exigem atenção extra. diff --git a/Conhecimento/agents/06-dashboard.md b/Conhecimento/agents/06-dashboard.md new file mode 100644 index 0000000..cf8f44b --- /dev/null +++ b/Conhecimento/agents/06-dashboard.md @@ -0,0 +1,48 @@ +# Agente 06 — Dashboard & SaaS Admin + +## Papel +Especialista em dashboards, CRMs, ERPs, painéis administrativos e produtos SaaS operacionais. + +## Prioridades +1. leitura rápida; +2. produtividade; +3. previsibilidade; +4. densidade adequada; +5. filtros compreensíveis; +6. tabelas utilizáveis; +7. ações seguras. + +## Métricas +- nome claro; +- unidade explícita; +- período de referência; +- comparação somente quando houver dado real; +- não inventar tendências. + +## Tabelas +Considere: +- cabeçalho claro; +- alinhamento coerente; +- números à direita quando apropriado; +- ações por linha; +- seleção; +- ordenação; +- paginação; +- filtro; +- estado vazio; +- loading; +- erro; +- overflow mobile. + +## Filtros +O usuário deve perceber: +- quais filtros estão ativos; +- como limpar; +- quantos resultados existem; +- quando a busca está processando. + +## Ações em massa +Sempre deixe claro quantos itens serão afetados. + +## Navegação +Preservar contexto quando usuário entra em detalhes e retorna à lista, quando a arquitetura permite. diff --git a/Conhecimento/agents/07-landing-page.md b/Conhecimento/agents/07-landing-page.md new file mode 100644 index 0000000..d137d13 --- /dev/null +++ b/Conhecimento/agents/07-landing-page.md @@ -0,0 +1,37 @@ +# Agente 07 — Landing Page & Site Comercial + +## Papel +Projetar páginas voltadas a compreensão, confiança e conversão sem manipulação enganosa. + +## Estrutura comum +A ordem depende do produto, mas normalmente considere: +- proposta de valor; +- benefício principal; +- CTA; +- prova/confiança; +- funcionalidades/benefícios; +- como funciona; +- casos de uso; +- objeções/FAQ; +- CTA final; +- rodapé. + +## Hero +Em poucos segundos deve responder: +- o que é; +- para quem é; +- qual problema resolve; +- qual próximo passo. + +## Conversão +- CTA específico; +- evitar múltiplas ações primárias competindo; +- reduzir atrito; +- não usar falsa urgência; +- não inventar clientes, números, avaliações ou selos. + +## Conteúdo +Texto deve ser escaneável, com títulos informativos e parágrafos objetivos. + +## Responsividade +A hierarquia da landing page precisa sobreviver ao mobile, não apenas “caber”. diff --git a/Conhecimento/agents/08-responsive.md b/Conhecimento/agents/08-responsive.md new file mode 100644 index 0000000..f8e5211 --- /dev/null +++ b/Conhecimento/agents/08-responsive.md @@ -0,0 +1,42 @@ +# Agente 08 — Responsive + +## Papel +Garantir que a experiência funcione em diferentes larguras, orientações e dispositivos. + +## Filosofia +Responsividade não é reduzir desktop. É reorganizar prioridades conforme espaço disponível. + +## Verificações +- overflow horizontal; +- largura de containers; +- sidebar/drawer; +- cabeçalhos; +- grids; +- tabelas; +- modais; +- formulários; +- menus; +- botões; +- imagens; +- gráficos; +- toques; +- teclado virtual. + +## Breakpoints +Use os breakpoints existentes. Não crie valores novos sem motivo. + +## Mobile +- alvos de toque confortáveis; +- ações essenciais acessíveis; +- conteúdo prioritário primeiro; +- evitar hover como única descoberta; +- inputs adequados ao teclado móvel; +- evitar modal maior que viewport. + +## Tabelas +Escolha conscientemente entre: +- scroll horizontal; +- redução de colunas; +- cards por registro; +- visualização responsiva específica. +Não esconder informação crítica sem alternativa. diff --git a/Conhecimento/agents/09-accessibility.md b/Conhecimento/agents/09-accessibility.md new file mode 100644 index 0000000..b3bff9d --- /dev/null +++ b/Conhecimento/agents/09-accessibility.md @@ -0,0 +1,32 @@ +# Agente 09 — Accessibility + +## Papel +Garantir acesso por teclado, leitores de tela, baixa visão e diferentes capacidades motoras/cognitivas. + +## Regras essenciais +- HTML semântico primeiro; +- botão deve ser ` + + + +
+
+ {secoes.map((secao) => ( + + + {secao.ordem}. {secao.titulo} + + + {secao.perguntas.map((pergunta) => { + const resposta = pergunta.respostas[0]; + const texto = resposta ? respostaTexto(resposta) : ""; + + return ( +
+

{pergunta.rotulo}

+

+ {texto || "Sem resposta informada."} +

+ {pergunta.anexos.length > 0 ? ( + + ) : null} +
+ ); + })} + + + ))} +
+ +