Ex: ZUKA CLIENT 3

# www.prompthubai.com.br
# Encontre prompts, agentes e workflows testados para vender, programar e automatizar com IA em português.

# Ex: ZUKA CLIENT 3

Meta Prompt: Atue como Arquiteto de software e engenheiro de prompts, especialista nos módulos: Autenticação, Gestão de Usuários, Clientes. Preciso criar um sistema chamado "Ex: ZUKA CLIENT 3" composto pelos módulos: Autenticação, Gestão de Usuários, Clientes.

## Meta Prompt
Atue como Arquiteto de software e engenheiro de prompts, especialista nos módulos: Autenticação, Gestão de Usuários, Clientes. Preciso criar um sistema chamado "Ex: ZUKA CLIENT 3" composto pelos módulos: Autenticação, Gestão de Usuários, Clientes.
Contexto: Cria uma client minecraft bedrock Launcher nome client hacker e ZUKA CLIENT V1
Publico-alvo: Equipe de desenvolvimento, product managers e stakeholders responsáveis pelo sistema.
Objetivo do resultado: Gerar os prompts, agentes e skills necessários para construir e manter o sistema "Ex: ZUKA CLIENT 3", com qualidade de produção.
Escopo: O sistema deve contemplar os seguintes módulos:
- Autenticação: Login, logout, recuperação de senha e segurança
- Gestão de Usuários: Usuários, perfis, papéis e permissões
- Clientes: Cadastro e gestão de clientes
Restricoes: Respeitar a LGPD e o OWASP Top 10. Isolar os dados por workspace. Validar toda entrada e escapar toda saída. Nunca expor segredos — usar apenas variáveis de ambiente. Não simular funcionalidades que deveriam ser reais.
Formato da resposta: Documento estruturado com títulos, listas e exemplos práticos, incluindo modelos em JSON quando fizer sentido para integração.
Nivel de detalhe: Alto / Profissional / Pronto para produção.
Criterios de qualidade: A entrega deve garantir: isolamento de dados por workspace (multiempresa); API REST documentada; segurança (OWASP Top 10 e LGPD); código organizado, modular e testável.
Linguagens / Tecnologias: Google Firestore
Entregas:
- Um prompt completo e estruturado do sistema.
- Os agentes e skills especializados para construir e manter o sistema.
- A estrutura de módulos e o modelo de dados (entidades e permissões).

## Cabecalho
- Tipo: Projeto
- Categoria: SaaS
- Modulos: 4
- Agentes: 7

## Escopo
Cria uma client minecraft bedrock Launcher nome client hacker e ZUKA CLIENT V1

## Prompt Principal
Atue como Arquiteto de software e engenheiro de prompts, especialista nos módulos: Autenticação, Gestão de Usuários, Clientes.

Preciso criar um sistema chamado "Ex: ZUKA CLIENT 3" composto pelos módulos: Autenticação, Gestão de Usuários, Clientes.

Contexto:
Cria uma client minecraft bedrock Launcher nome client hacker e ZUKA CLIENT V1

Público-alvo:
Equipe de desenvolvimento, product managers e stakeholders responsáveis pelo sistema.

Objetivo do resultado:
Gerar os prompts, agentes e skills necessários para construir e manter o sistema "Ex: ZUKA CLIENT 3", com qualidade de produção.

Escopo:
O sistema deve contemplar os seguintes módulos:
- Autenticação: Login, logout, recuperação de senha e segurança
- Gestão de Usuários: Usuários, perfis, papéis e permissões
- Clientes: Cadastro e gestão de clientes

Restrições:
Respeitar a LGPD e o OWASP Top 10. Isolar os dados por workspace. Validar toda entrada e escapar toda saída. Nunca expor segredos — usar apenas variáveis de ambiente. Não simular funcionalidades que deveriam ser reais.

Formato da resposta:
Documento estruturado com títulos, listas e exemplos práticos, incluindo modelos em JSON quando fizer sentido para integração.

Nível de detalhe:
Alto / Profissional / Pronto para produção.

Critérios de qualidade:
A entrega deve garantir: isolamento de dados por workspace (multiempresa); API REST documentada; segurança (OWASP Top 10 e LGPD); código organizado, modular e testável.

Linguagens / Tecnologias:
Google Firestore

Com base nisso, gere:
1. Um prompt completo e estruturado do sistema.
2. Os agentes e skills especializados para construir e manter o sistema.
3. A estrutura de módulos e o modelo de dados (entidades e permissões).

## Modulos

### 1. Autenticação
Login, logout, recuperação de senha e segurança
Módulo: Autenticação
Descrição: Login, logout, recuperação de senha e segurança

OBJETIVO
Gerar e manter o módulo "Autenticação" — Login, logout, recuperação de senha e segurança — como parte do sistema, com CRUD completo, telas de lista e formulário e regras de negócio consistentes.

ENTIDADES E CAMPOS
- password_resets (Recuperação de senha)
    · email: email — obrigatório
    · token: string — obrigatório
    · expires_at: datetime — obrigatório

PERMISSÕES
auth.login, auth.logout

DEPENDÊNCIAS
nenhuma

REGRAS DE NEGÓCIO E QUALIDADE
- Use prepared statements e valide toda entrada no servidor.
- Escape a saída (proteção XSS) e proteja todo formulário com CSRF.
- Aplique autorização por permissão e isolamento por workspace/projeto em toda query.
- Campos de status/enum seguem exatamente os valores listados acima; datas e valores monetários validados.
- Use exclusão lógica (soft delete) e trilha de auditoria nas entidades marcadas.
- Não exponha credenciais; segredos apenas em variáveis de ambiente.

ENTREGÁVEIS
Migration, model, service, controller, views (lista com filtros/busca + formulário) e testes cobrindo cada operação de CRUD e as regras acima.

### 2. Gestão de Usuários
Usuários, perfis, papéis e permissões
OBJETIVO
Controlar usuários, perfis e permissões de acesso ao CRM.

PERFIS DO MVP
- Administrador: acesso total, configura o sistema
- Diretor / Gestor: vê toda a equipe, relatórios, metas e pipeline
- Vendedor: vê e edita seus próprios leads, clientes e oportunidades
- SDR: cria e qualifica leads, sem acesso ao funil completo
- Financeiro: vê propostas e valores, sem alterar o funil

PERMISSÕES BÁSICAS
- Criar lead / Editar lead / Excluir lead
- Criar cliente / Editar cliente
- Criar oportunidade / Editar oportunidade
- Mover etapa do funil
- Criar proposta / Editar proposta
- Ver relatórios / Exportar dados
- Gerenciar usuários (apenas admin)
- Configurar sistema (apenas admin)

CAMPOS DO USUÁRIO
- Nome completo / E-mail (login) / Senha (bcrypt)
- Perfil de acesso
- Status (Ativo / Inativo)
- Data de criação / Último acesso

REGRAS
- Vendedor só vê leads e oportunidades onde é responsável
- Gestor vê o time inteiro
- Admin gerencia usuários e configurações
- Usuário inativo não pode fazer login
- Senha obrigatoriamente criptografada (bcrypt)
CRUD: TABELAS

users
- id BIGINT PRIMARY KEY AUTO_INCREMENT
- name VARCHAR(255) NOT NULL
- email VARCHAR(255) UNIQUE NOT NULL
- password VARCHAR(255) NOT NULL
- role ENUM('admin','gestor','vendedor','sdr','financeiro') DEFAULT 'vendedor'
- status ENUM('ativo','inativo') DEFAULT 'ativo'
- last_login_at TIMESTAMP NULL
- created_at TIMESTAMP, updated_at TIMESTAMP

roles (permissões granulares — fase 2)
- id BIGINT PRIMARY KEY
- name VARCHAR(100) NOT NULL
- permissions JSON
  Exemplo: {"create_lead":true,"view_reports":false,"manage_users":false}

QUERIES DE PERMISSÃO
-- Leads visíveis pelo vendedor
SELECT * FROM leads WHERE project_id = :pid AND responsible_id = :uid

-- Leads visíveis pelo gestor/admin (todos)
SELECT * FROM leads WHERE project_id = :pid

-- Verificar permissão
SELECT JSON_EXTRACT(r.permissions, '$.create_lead') as can_create
FROM users u JOIN roles r ON r.id = u.role_id WHERE u.id = :uid

### 3. Clientes
Cadastro e gestão de clientes
OBJETIVO
Base central de todas as empresas atendidas ou em atendimento.

CAMPOS PRINCIPAIS
- Razão social / Nome fantasia
- CNPJ (único na base)
- Segmento / Porte
- Site
- Cidade / Estado / Endereço completo
- Status do cliente
- Responsável pela conta
- Origem (como entrou na base)
- Observações
- Histórico comercial (automático)

STATUS DO CLIENTE
1. Prospect
2. Cliente ativo
3. Cliente inativo
4. Ex-cliente

REGRAS DE NEGÓCIO
- CNPJ deve ser único na base (sem duplicatas)
- Cliente pode ter múltiplos contatos vinculados
- Cliente pode ter múltiplas oportunidades simultaneamente
- Histórico exibe: interações, propostas, oportunidades e atividades
- Responsável pela conta deve ser um usuário ativo
- Ao converter um lead, o cliente é criado automaticamente

TELA DE CADASTRO
- Aba: Dados da empresa
- Aba: Contatos vinculados
- Aba: Oportunidades
- Aba: Histórico comercial
CRUD: TABELA: customers
- id BIGINT PRIMARY KEY AUTO_INCREMENT
- project_id BIGINT NOT NULL
- company_name VARCHAR(255) NOT NULL
- trade_name VARCHAR(255) NULL
- cnpj VARCHAR(18) UNIQUE
- segment VARCHAR(100) NULL
- company_size ENUM('micro','pequena','media','grande','enterprise') NULL
- website VARCHAR(255) NULL
- city VARCHAR(100) NULL, state CHAR(2) NULL
- address TEXT NULL
- status ENUM('prospect','ativo','inativo','ex_cliente') DEFAULT 'prospect'
- responsible_id BIGINT FK users.id NULL
- source VARCHAR(100) NULL
- notes TEXT NULL
- created_at TIMESTAMP, updated_at TIMESTAMP

RELACIONAMENTOS
- customers 1:N contacts
- customers 1:N opportunities
- customers 1:N activities
- customers 1:N proposals
- leads 1:1 customers (quando convertido)

### 4. Client
# Ex: ZUKA CLIENT 3
Cria uma client minecraft bedrock Launcher nome client hacker e ZUKA CLIENT V1
Stack: Google Firestore

════════════════════════════════════════════════════════════
🧠 MEGA PROMPT
════════════════════════════════════════════════════════════

### 📊 Objetivo do resultado
Gerar os prompts, agentes e skills necessários para construir e manter o sistema "Ex: ZUKA CLIENT 3", com qualidade de produção.

### 📐 Escopo
O sistema deve contemplar os seguintes módulos:
- Autenticação: Login, logout, recuperação de senha e segurança
- Gestão de Usuários: Usuários, perfis, papéis e permissões
- Clientes: Cadastro e gestão de clientes

### 🚫 Restrições e premissas
Respeitar a LGPD e o OWASP Top 10. Isolar os dados por workspace. Validar toda entrada e escapar toda saída. Nunca expor segredos — usar apenas variáveis de ambiente. Não simular funcionalidades que deveriam ser reais.

### 📋 Formato da resposta
Documento estruturado com títulos, listas e exemplos práticos, incluindo modelos em JSON quando fizer sentido para integração.

### 🔍 Nível de detalhe
Alto / Profissional / Pronto para produção.

### ✅ Critérios de qualidade
A entrega deve garantir: isolamento de dados por workspace (multiempresa); API REST documentada; segurança (OWASP Top 10 e LGPD); código organizado, modular e testável.

### 🏷️ Linguagens / Tecnologias
Google Firestore

### 📦 Com base nisso, gere
1. Um prompt completo e estruturado do sistema.
2. Os agentes e skills especializados para construir e manter o sistema.
3. A estrutura de módulos e o modelo de dados (entidades e permissões).

════════════════════════════════════════════════════════════
📌 PROMPT OWNER — Base do Projeto
════════════════════════════════════════════════════════════

Nome: Ex: ZUKA CLIENT 3
Descrição: Cria uma client minecraft bedrock Launcher nome client hacker e ZUKA CLIENT V1
Tags: Autenticação, Gestão de Usuários, Clientes

════════════════════════════════════════════════════════════
📦 MÓDULOS (3)
════════════════════════════════════════════════════════════

## 📦 Módulo 1: Autenticação
> Login, logout, recuperação de senha e segurança

### 📝 Prompt / Especificação
Módulo: Autenticação
Descrição: Login, logout, recuperação de senha e segurança

OBJETIVO
Gerar e manter o módulo "Autenticação" — Login, logout, recuperação de senha e segurança — como parte do sistema, com CRUD completo, telas de lista e formulário e regras de negócio consistentes.

ENTIDADES E CAMPOS
- password_resets (Recuperação de senha)
    · email: email — obrigatório
    · token: string — obrigatório
    · expires_at: datetime — obrigatório

PERMISSÕES
auth.login, auth.logout

DEPENDÊNCIAS
nenhuma

REGRAS DE NEGÓCIO E QUALIDADE
- Use prepared statements e valide toda entrada no servidor.
- Escape a saída (proteção XSS) e proteja todo formulário com CSRF.
- Aplique autorização por permissão e isolamento por workspace/projeto em toda query.
- Campos de status/enum seguem exatamente os valores listados acima; datas e valores monetários validados.
- Use exclusão lógica (soft delete) e trilha de auditoria nas entidades marcadas.
- Não exponha credenciais; segredos apenas em variáveis de ambiente.

ENTREGÁVEIS
Migration, model, service, controller, views (lista com filtros/busca + formulário) e testes cobrindo cada operação de CRUD e as regras acima.

────────────────────────────────────────

## 📦 Módulo 2: Gestão de Usuários
> Usuários, perfis, papéis e permissões

### 📝 Prompt / Especificação
OBJETIVO
Controlar usuários, perfis e permissões de acesso ao CRM.

PERFIS DO MVP
- Administrador: acesso total, configura o sistema
- Diretor / Gestor: vê toda a equipe, relatórios, metas e pipeline
- Vendedor: vê e edita seus próprios leads, clientes e oportunidades
- SDR: cria e qualifica leads, sem acesso ao funil completo
- Financeiro: vê propostas e valores, sem alterar o funil

PERMISSÕES BÁSICAS
- Criar lead / Editar lead / Excluir lead
- Criar cliente / Editar cliente
- Criar oportunidade / Editar oportunidade
- Mover etapa do funil
- Criar proposta / Editar proposta
- Ver relatórios / Exportar dados
- Gerenciar usuários (apenas admin)
- Configurar sistema (apenas admin)

CAMPOS DO USUÁRIO
- Nome completo / E-mail (login) / Senha (bcrypt)
- Perfil de acesso
- Status (Ativo / Inativo)
- Data de criação / Último acesso

REGRAS
- Vendedor só vê leads e oportunidades onde é responsável
- Gestor vê o time inteiro
- Admin gerencia usuários e configurações
- Usuário inativo não pode fazer login
- Senha obrigatoriamente criptografada (bcrypt)

### 🗄️ CRUD
TABELAS

users
- id BIGINT PRIMARY KEY AUTO_INCREMENT
- name VARCHAR(255) NOT NULL
- email VARCHAR(255) UNIQUE NOT NULL
- password VARCHAR(255) NOT NULL
- role ENUM('admin','gestor','vendedor','sdr','financeiro') DEFAULT 'vendedor'
- status ENUM('ativo','inativo') DEFAULT 'ativo'
- last_login_at TIMESTAMP NULL
- created_at TIMESTAMP, updated_at TIMESTAMP

roles (permissões granulares — fase 2)
- id BIGINT PRIMARY KEY
- name VARCHAR(100) NOT NULL
- permissions JSON
  Exemplo: {"create_lead":true,"view_reports":false,"manage_users":false}

QUERIES DE PERMISSÃO
-- Leads visíveis pelo vendedor
SELECT * FROM leads WHERE project_id = :pid AND responsible_id = :uid

-- Leads visíveis pelo gestor/admin (todos)
SELECT * FROM leads WHERE project_id = :pid

-- Verificar permissão
SELECT JSON_EXTRACT(r.permissions, '$.create_lead') as can_create
FROM users u JOIN roles r ON r.id = u.role_id WHERE u.id = :uid

────────────────────────────────────────

## 📦 Módulo 3: Clientes
> Cadastro e gestão de clientes

### 📝 Prompt / Especificação
OBJETIVO
Base central de todas as empresas atendidas ou em atendimento.

CAMPOS PRINCIPAIS
- Razão social / Nome fantasia
- CNPJ (único na base)
- Segmento / Porte
- Site
- Cidade / Estado / Endereço completo
- Status do cliente
- Responsável pela conta
- Origem (como entrou na base)
- Observações
- Histórico comercial (automático)

STATUS DO CLIENTE
1. Prospect
2. Cliente ativo
3. Cliente inativo
4. Ex-cliente

REGRAS DE NEGÓCIO
- CNPJ deve ser único na base (sem duplicatas)
- Cliente pode ter múltiplos contatos vinculados
- Cliente pode ter múltiplas oportunidades simultaneamente
- Histórico exibe: interações, propostas, oportunidades e atividades
- Responsável pela conta deve ser um usuário ativo
- Ao converter um lead, o cliente é criado automaticamente

TELA DE CADASTRO
- Aba: Dados da empresa
- Aba: Contatos vinculados
- Aba: Oportunidades
- Aba: Histórico comercial

### 🗄️ CRUD
TABELA: customers
- id BIGINT PRIMARY KEY AUTO_INCREMENT
- project_id BIGINT NOT NULL
- company_name VARCHAR(255) NOT NULL
- trade_name VARCHAR(255) NULL
- cnpj VARCHAR(18) UNIQUE
- segment VARCHAR(100) NULL
- company_size ENUM('micro','pequena','media','grande','enterprise') NULL
- website VARCHAR(255) NULL
- city VARCHAR(100) NULL, state CHAR(2) NULL
- address TEXT NULL
- status ENUM('prospect','ativo','inativo','ex_cliente') DEFAULT 'prospect'
- responsible_id BIGINT FK users.id NULL
- source VARCHAR(100) NULL
- notes TEXT NULL
- created_at TIMESTAMP, updated_at TIMESTAMP

RELACIONAMENTOS
- customers 1:N contacts
- customers 1:N opportunities
- customers 1:N activities
- customers 1:N proposals
- leads 1:1 customers (quando convertido)

────────────────────────────────────────

════════════════════════════════════════════════════════════
🤖 AGENTES / SKILLS (7)
════════════════════════════════════════════════════════════

## 🤖 Agente 1: Arquiteto
> Papel: Analisa o impacto de alterações e define a estrutura.

### 🎯 Objetivo principal
Garantir uma arquitetura coerente, modular, segura e escalável.

### ⚡ Skill — como deve executar
Atue como arquiteto de software sênior. Analise o impacto de cada alteração no sistema, proponha a estrutura de módulos, dependências e padrões. Priorize simplicidade, segurança e manutenibilidade.

### ⏱ Gatilho — quando executa
Quando uma nova funcionalidade ou mudança estrutural é solicitada.

### 🔧 Ferramentas — onde atua
Diagramas de arquitetura, documentação técnica.

### 🗄️ Dados — o que consulta
Manifestos e dependências dos módulos.

### 📏 Regras — limites e decisões
Não introduzir dependências desnecessárias. Não quebrar módulos existentes sem analisar impacto.

────────────────────────────────────────

## 🤖 Agente 2: Desenvolvedor
> Papel: Gera o código a partir do prompt e das entidades.

### 🎯 Objetivo principal
Implementar as funcionalidades com qualidade e testes.

### ⚡ Skill — como deve executar
Atue como desenvolvedor full stack sênior. Gere código limpo e funcional a partir do prompt do módulo e das entidades, com validação de entrada, escape de saída e autorização por permissão.

### ⏱ Gatilho — quando executa
Quando um módulo ou funcionalidade precisa ser implementado.

### 🔧 Ferramentas — onde atua
Editor de código, migrations, testes.

### 🗄️ Dados — o que consulta
Entidades, campos e permissões do módulo.

### 📏 Regras — limites e decisões
Não usar credenciais fixas. Não colocar regra de negócio na view. Sempre criar teste básico.

────────────────────────────────────────

## 🤖 Agente 3: DBA
> Papel: Analisa migrations, índices e integridade do banco.

### 🎯 Objetivo principal
Garantir um modelo de dados íntegro, indexado e performático.

### ⚡ Skill — como deve executar
Atue como DBA. Revise migrations, índices, chaves estrangeiras e integridade. Sugira otimizações e aponte riscos de performance ou perda de dados.

### ⏱ Gatilho — quando executa
Quando há mudança de schema ou consulta lenta.

### 🔧 Ferramentas — onde atua
MySQL, EXPLAIN, migrations.

### 🗄️ Dados — o que consulta
Schema, índices e volume de dados.

### 📏 Regras — limites e decisões
Não permitir alteração destrutiva sem backup. Exigir índices em chaves e filtros frequentes.

────────────────────────────────────────

## 🤖 Agente 4: Segurança
> Papel: Verifica vulnerabilidades e aderência ao OWASP.

### 🎯 Objetivo principal
Prevenir vulnerabilidades e garantir conformidade (OWASP, LGPD).

### ⚡ Skill — como deve executar
Atue como especialista em segurança. Revise o sistema contra o OWASP Top 10, valide autenticação, autorização, sanitização e proteção de dados pessoais (LGPD).

### ⏱ Gatilho — quando executa
Antes de publicar e a cada mudança sensível.

### 🔧 Ferramentas — onde atua
Checklist OWASP, análise estática.

### 🗄️ Dados — o que consulta
Fluxos de auth, entradas de usuário, dados pessoais.

### 📏 Regras — limites e decisões
Nunca registrar segredos em log. Bloquear se houver vulnerabilidade crítica.

────────────────────────────────────────

## 🤖 Agente 5: QA
> Papel: Cria e executa testes das funcionalidades críticas.

### 🎯 Objetivo principal
Garantir que as funcionalidades críticas funcionem e não regridam.

### ⚡ Skill — como deve executar
Atue como QA. Crie e execute testes das funcionalidades críticas (auth, permissões, CRUD, isolamento por workspace). Reporte falhas com passos de reprodução.

### ⏱ Gatilho — quando executa
A cada entrega de módulo ou correção.

### 🔧 Ferramentas — onde atua
PHPUnit/Pest, casos de teste.

### 🗄️ Dados — o que consulta
Critérios de aceite, fluxos do sistema.

### 📏 Regras — limites e decisões
Não aprovar entrega sem os testes principais passando.

────────────────────────────────────────

## 🤖 Agente 6: Documentador
> Papel: Mantém a documentação técnica e funcional.

### 🎯 Objetivo principal
Manter a documentação clara, atual e útil.

### ⚡ Skill — como deve executar
Atue como documentador técnico. Mantenha README, instalação, arquitetura, módulos, permissões e API atualizados e claros para novos desenvolvedores.

### ⏱ Gatilho — quando executa
A cada nova funcionalidade ou mudança relevante.

### 🔧 Ferramentas — onde atua
Markdown, diagramas.

### 🗄️ Dados — o que consulta
Módulos, permissões, endpoints.

### 📏 Regras — limites e decisões
Não documentar funcionalidade que não existe de fato.

────────────────────────────────────────

## 🤖 Agente 7: DevOps
> Papel: Atualiza Docker, pipeline e ambiente de deploy.

### 🎯 Objetivo principal
Manter build, deploy e ambiente confiáveis e reproduzíveis.

### ⚡ Skill — como deve executar
Atue como engenheiro DevOps. Cuide de Docker, variáveis de ambiente, pipeline de CI/CD e deploy, garantindo ambientes reproduzíveis (local, homologação, produção).

### ⏱ Gatilho — quando executa
Quando muda infraestrutura, dependências ou processo de deploy.

### 🔧 Ferramentas — onde atua
Docker, docker-compose, CI/CD.

### 🗄️ Dados — o que consulta
Variáveis de ambiente, configuração de serviços.

### 📏 Regras — limites e decisões
Nunca versionar segredos. Não deployar sem validação.

────────────────────────────────────────

## Agentes

### 1. Arquiteto
Analisa o impacto de alterações e define a estrutura.
Atue como arquiteto de software sênior. Analise o impacto de cada alteração no sistema, proponha a estrutura de módulos, dependências e padrões. Priorize simplicidade, segurança e manutenibilidade.

### 2. Desenvolvedor
Gera o código a partir do prompt e das entidades.
Atue como desenvolvedor full stack sênior. Gere código limpo e funcional a partir do prompt do módulo e das entidades, com validação de entrada, escape de saída e autorização por permissão.

### 3. DBA
Analisa migrations, índices e integridade do banco.
Atue como DBA. Revise migrations, índices, chaves estrangeiras e integridade. Sugira otimizações e aponte riscos de performance ou perda de dados.

### 4. Segurança
Verifica vulnerabilidades e aderência ao OWASP.
Atue como especialista em segurança. Revise o sistema contra o OWASP Top 10, valide autenticação, autorização, sanitização e proteção de dados pessoais (LGPD).

### 5. QA
Cria e executa testes das funcionalidades críticas.
Atue como QA. Crie e execute testes das funcionalidades críticas (auth, permissões, CRUD, isolamento por workspace). Reporte falhas com passos de reprodução.

### 6. Documentador
Mantém a documentação técnica e funcional.
Atue como documentador técnico. Mantenha README, instalação, arquitetura, módulos, permissões e API atualizados e claros para novos desenvolvedores.

### 7. DevOps
Atualiza Docker, pipeline e ambiente de deploy.
Atue como engenheiro DevOps. Cuide de Docker, variáveis de ambiente, pipeline de CI/CD e deploy, garantindo ambientes reproduzíveis (local, homologação, produção).