Developer Portal - Labzz LLC

2. Restrições e Proibições

Este capítulo estabelece as proibições absolutas e restrições contextuais para o uso de vibecoding. Violações destas regras podem resultar em ações disciplinares graves, incluindo rescisão de contrato e responsabilização legal.

⚠️ ATENÇÃO: Este é o capítulo mais crítico das diretrizes. Leia com atenção máxima.

2.1. Proibições Absolutas (NUNCA FAZER)

2.1.1. "Fucking Code" - Código Irresponsável

Definição:

"Fucking Code" (também conhecido como "vibecoding shit") refere-se à prática irresponsável de solicitar a ferramentas de IA a criação de sistemas complexos e completos sem compreensão arquitetural adequada.

Exemplos de solicitações PROIBIDAS:

❌ "Crie uma plataforma completa de e-commerce"
❌ "Desenvolva um sistema de gestão de clientes do zero"
❌ "Implemente um CRM completo"
❌ "Faça uma rede social"
❌ "Altere essa funcionalidade pra xxx"
❌ "Nao gostei disso, poderia ser isso"
❌ "Nao esta funcionando, resolva ."
❌ "Altere essa funcionalidade pra xxx"
❌ "Integre com supabase"
❌ "Crie um sistema de autenticação completo com login, registro, 2FA e recuperação de senha"
❌ "Desenvolva uma API REST completa para [qualquer sistema complexo]"

Por que é proibido:

Falta de compreensão: Desenvolvedor não entende a arquitetura gerada, provalmente vulnerável(90% de chance)
Vulnerabilidades ocultas: Código complexo pode conter falhas de segurança não-óbvias
Não-manutenível: Código gerado em massa é difícil de manter e evoluir, logo, estamos falando de algo que nao tem valor.
Violação de responsabilidade: Desenvolvedor não pode ser responsável por código que não compreende
Alto risco: Sistemas complexos têm alta probabilidade de erros críticos

Consequências:

Uma única solicitação de "fucking code" em sistema crítico pode resultar em:
- Suspensão imediata (90 dias)
- Rescisão de contrato (se resultar em incidente)
- Responsabilização por danos causados

Alternativa CORRETA - Divisão em Tarefas Atômicas:

✅ PERMITIDO: Dividir em tarefas pequenas e revisáveis

// Exemplo: Sistema de autenticação dividido corretamente
 
// Tarefa 1: Interface de usuário
interface User {
    id: string;
    email: string;
    passwordHash: string;
    createdAt: Date;
}
 
// Tarefa 2: Função de hash de senha
import * as bcrypt from 'bcrypt';
 
async function hashPassword(plainPassword: string): Promise<string> {
    const saltRounds = 12;
    return await bcrypt.hash(plainPassword, saltRounds);
}
 
// Tarefa 3: Função de validação de senha
async function verifyPassword(plain: string, hash: string): Promise<boolean> {
    return await bcrypt.compare(plain, hash);
}
 
// Tarefa 4: Geração de JWT (após revisão das anteriores)
// Tarefa 5: Middleware de validação (após revisão das anteriores)
// Cada tarefa: menos de 50 linhas, revisada individualmente

Regra de Ouro:

Se você não consegue revisar e compreender completamente em 15 minutos, o código gerado é muito complexo para vibecoding.

2.1.2. Dados Sensíveis em Prompts

NUNCA inclua os seguintes tipos de dados em prompts para ferramentas de IA:

Credenciais e Secrets:

❌ Senhas (mesmo de teste)
❌ API keys e tokens de acesso
❌ Chaves privadas (SSH, GPG, certificados)
❌ Strings de conexão com credenciais
❌ JWTs ou session tokens
❌ Credenciais de banco de dados
❌ .env ou credenciais

Exemplo PROIBIDO:

// ❌ PROIBIDO: Compartilhar com IA
const dbConfig = {
    host: 'prod-db.empresa.com',
    user: 'admin',
    password: 'Senh@Pr0d123!',  // NUNCA!
    database: 'production_db'
};
 
// Prompt para IA: "Por que esta conexão está falhando?"
// VIOLAÇÃO: Expôs host, user, password real!

Alternativa CORRETA:

// ✅ PERMITIDO: Dados anonimizados
const dbConfig = {
    host: process.env.DB_HOST,
    user: process.env.DB_USER,
    password: process.env.DB_PASSWORD,
    database: process.env.DB_NAME
};
 
// Prompt para IA: "Como configurar conexão PostgreSQL com variáveis de ambiente?"
// ✓ Sem exposição de dados reais

Dados de Aplicação:

❌ Logs com dados reais de usuários
❌ Dumps de banco de dados (mesmo parciais)
❌ Schemas que revelam lógica de negócio proprietária
❌ Queries com dados reais em cláusulas WHERE
❌ Responses de API com dados de clientes

Exemplo PROIBIDO:

-- ❌ PROIBIDO: Debug de query com dados reais
SELECT * FROM orders 
WHERE customer_email = 'joao.silva@clienteempresa.com'
AND total maior que 5000;
 
-- Prompt: "Esta query está lenta, como otimizar?"
-- VIOLAÇÃO: Expôs email real de cliente!

Alternativa CORRETA:

-- ✅ PERMITIDO: Query anonimizada
SELECT * FROM orders 
WHERE customer_email = ?
AND total maior que ?;
 
-- Prompt: "Como otimizar query com índices em orders (customer_email, total)?"
-- ✓ Sem exposição de dados

2.1.3. Informações Privilegiadas

Lista completa de informações PROIBIDAS conforme LGPD Art. 5, II:

Dados Pessoais Identificáveis:

❌ Nomes completos de pessoas reais
❌ Endereços de email (pessoais ou corporativos)
❌ Números de telefone
❌ Endereços físicos
❌ IPs de usuários específicos
❌ Usernames ou handles únicos

Documentos:

❌ CPF
❌ CNPJ
❌ RG
❌ CNH
❌ Passaportes
❌ Números de cartões de crédito (mesmo parciais)

Informações Financeiras:

❌ Valores de salários e remunerações
❌ Custos de projetos
❌ Margens de lucro
❌ Precificação estratégica
❌ Informações de faturamento
❌ Ganhos ou earnings
❌ Informações de contas bancárias

Informações de Clientes:

❌ Nomes de empresas clientes
❌ Dados contratuais (valores, prazos, SLAs)
❌ Informações comerciais confidenciais
❌ Roadmaps de produtos de clientes
❌ Volumes de uso ou consumo

Dados Sensíveis (LGPD Art. 5, II):

❌ Origem racial ou étnica
❌ Convicções religiosas
❌ Opiniões políticas
❌ Filiação sindical
❌ Dados de saúde
❌ Dados genéticos
❌ Dados biométricos
❌ Dados sobre vida sexual ou orientação sexual

Informações Biométricas:

❌ Fotos de rostos identificáveis
❌ Impressões digitais
❌ Scans de retina/íris
❌ Dados de reconhecimento facial
❌ Padrões de voz

Geolocalização:

❌ Coordenadas GPS de indivíduos
❌ Histórico de localização
❌ Endereços residenciais

Propriedade Intelectual:

❌ Algoritmos proprietários completos
❌ Lógica de negócio confidencial
❌ Trade secrets
❌ Fórmulas ou métodos patenteados

2.1.4. Sistemas Críticos Proibidos

Tipos de sistemas onde vibecoding é PROIBIDO sem aprovação formal:

Segurança e Autenticação:

❌ Módulos de login e autenticação
❌ Sistemas de autorização e controle de acesso
❌ Implementações de criptografia
❌ Gerenciamento de sessões
❌ Two-Factor Authentication (2FA)
❌ Single Sign-On (SSO)
❌ OAuth/OIDC implementations

Financeiro:

❌ Processamento de pagamentos
❌ Gateways de pagamento
❌ Sistemas de cobrança e faturamento
❌ Cálculos de impostos
❌ Conciliação bancária
❌ Sistemas de contabilidade

Dados Sensíveis:

❌ Sistemas de saúde (prontuários, exames, etc.)
❌ Processamento de dados biométricos
❌ Sistemas educacionais com dados de menores
❌ Plataformas de consentimento LGPD
❌ Sistemas de anonimização/pseudonimização

Infraestrutura Crítica:

❌ Sistemas de deploy em produção
❌ Configurações de firewall e segurança de rede
❌ Scripts de backup e recuperação
❌ Sistemas de monitoramento de segurança
❌ Infraestrutura as Code (IaC) de produção

2.1.5. Plataformas de Desenvolvimento Não-Homologadas

PROIBIDO ABSOLUTAMENTE o uso de plataformas não-aprovadas para desenvolvimento com dados sensíveis:

Lovable e Plataformas Similares:

❌ Criar produtos no Lovable com informações sensíveis da empresa
❌ Desenvolver dashboards no Lovable com dados privilegiados
❌ Subir código com credenciais, dados de clientes ou informações confidenciais
❌ Utilizar Lovable para prototipagem com dados reais de produção
❌ Compartilhar schemas de banco de dados com informações críticas

Cursor e Ferramentas Compatíveis:

❌ Criar dashboards com informações privilegiadas em Cursor
❌ Desenvolver interfaces que exibam dados financeiros reais
❌ Implementar relatórios com dados sensíveis LGPD
❌ Gerar código que processe informações confidenciais sem aprovação

Uploads de Relatórios e Dados Financeiros:

❌ Subir relatórios da Stripe ou qualquer gateway de pagamento
❌ Upload de planilhas com dados de faturamento
❌ Compartilhar relatórios de analytics com dados de clientes
❌ Enviar dashboards financeiros para plataformas não-homologadas
❌ Fazer upload de exports de CRM com dados de clientes
❌ Compartilhar relatórios de vendas com informações privilegiadas

Por que é proibido:

Falta de controle de dados: Plataformas não-homologadas não têm garantias de proteção de dados conforme LGPD
Risco de vazamento: Dados podem ser armazenados em servidores fora do Brasil sem conformidade legal
Violação de propriedade intelectual: Informações estratégicas podem ser expostas
Não-conformidade LGPD: Transferência de dados pessoais para processadores não-autorizados (Art. 33)
Risco de auditoria: Multas podem chegar a R$ 50 milhões por violação (LGPD Art. 52)

Exemplos de violações críticas:

// ❌ PROIBIDO: Dashboard no Lovable com dados reais
interface SalesReport {
    cliente: "Empresa XYZ Ltda",  // VIOLAÇÃO: Nome real de cliente
    faturamento: 150000,          // VIOLAÇÃO: Dados financeiros
    comissao: 15000,              // VIOLAÇÃO: Informações privilegiadas
    vendedor: "João Silva"        // VIOLAÇÃO: Dados pessoais
}
 
// ❌ PROIBIDO: Upload de relatório Stripe
// Arquivo: stripe-payments-2024.csv
// VIOLAÇÃO: Contém transações reais, emails, valores

// ❌ PROIBIDO: Código gerado no Cursor com dados sensíveis
class FinancialDashboard {
    public function getRevenue() {
        // Query com dados reais de clientes
        return DB::table('clients')
            ->where('name', 'Cliente Real Ltda')  // VIOLAÇÃO!
            ->sum('contract_value');              // VIOLAÇÃO!
    }
}

Alternativa CORRETA - Uso Seguro:

// ✅ PERMITIDO: Desenvolvimento local com dados fake
interface SalesReport {
    cliente: "Cliente Exemplo",  // Dado fictício
    faturamento: 0,              // Valor placeholder
    comissao: 0,                 // Valor placeholder
    vendedor: "User Test"        // Usuário de teste
}
 
// Desenvolvimento em ambiente local aprovado
// Dados reais APENAS após deploy em infraestrutura homologada

// ✅ PERMITIDO: Estrutura sem dados sensíveis
class FinancialDashboard {
    public function getRevenue(string $clientId) {
        // Estrutura genérica sem dados hardcoded
        return $this->repository->getClientRevenue($clientId);
    }
}
 
// Testes com dados anonimizados via Faker

Checklist antes de usar plataformas de desenvolvimento:

A plataforma está na lista oficial de ferramentas aprovadas?
Vou compartilhar APENAS estruturas e código genérico?
Não há dados reais de clientes, faturamento ou informações privilegiadas?
Não há credenciais, tokens ou API keys?
Tenho aprovação formal para usar esta ferramenta neste projeto?
O código será revisado antes de ir para produção?

Consequências de violação:

Uso de plataforma não-homologada com dados sensíveis:
- Suspensão imediata (90 dias)
- Notificação obrigatória à ANPD (Lei 13.709/2018)
- Auditoria completa de segurança
- Possível rescisão por justa causa
- Responsabilização pessoal por multas LGPD

Processo de homologação de novas plataformas:

Se você acredita que uma plataforma deve ser aprovada:

Solicitar análise formal ao time de Security
Documentar: políticas de privacidade, localização de dados, conformidade LGPD
Aguardar aprovação por escrito (SLA: 15 dias úteis)
NÃO usar até aprovação oficial publicada

Plataformas atualmente homologadas:

Consultar lista oficial em Ferramentas Permitidas
Atualização: Trimestral

⚠️ CRÍTICO: Lovable, V0.dev e plataformas de "geração visual de código" são NÃO-HOMOLOGADAS para uso com qualquer dado real da empresa.

2.2. Restrições Contextuais

2.2.1. Uso em Produção

Toda implementação gerada por IA que vá para produção DEVE:

Code Review Obrigatório:
- Revisão completa linha por linha
- Aprovação de desenvolvedor Sênior
- Validação de segurança específica
Testes Automatizados:
- Testes unitários (cobertura maior que 80%)
- Testes de integração
- Testes de segurança automatizados
Análise Estática:
- SAST (Static Application Security Testing)
- Ferramentas de linting configuradas
- SonarQube Quality Gate: PASSED
Validação de Desenvolvedor:
- Desenvolvedor compreende 100% do código
- Capaz de explicar cada linha
- Documentação adequada criada

2.2.2. Anonimização de Dados

Quando precisar compartilhar código com dados para debugging:

Técnicas de anonimização:

// ✅ CORRETO: Anonimização adequada
use Faker\Factory as Faker;
 
$faker = Faker::create('pt_BR');
 
$testUser = [
    'name' => $faker->name,  // "Maria Silva" (fake)
    'email' => $faker->safeEmail,  // "example@example.com"
    'cpf' => $faker->numerify('###########'),  // Números aleatórios
    'phone' => $faker->phoneNumber,
    'address' => $faker->address,
];
 
// Agora seguro para compartilhar com IA

// ✅ CORRETO: Mascaramento de dados
function anonymizeForAI(data: any): any {
    return {
        ...data,
        email: data.email ? 'user@example.com' : null,
        name: 'Test User',
        cpf: '000.000.000-00',
        phone: '+55 11 00000-0000',
        // Manter apenas estrutura, não dados reais
    };
}

Validação de anonimização:

Antes de compartilhar, verifique:

2.2.3. Arquivos e Documentos

NUNCA faça upload ou compartilhe:

❌ PDFs com dados sensíveis (contratos, documentos de clientes)
❌ Planilhas com dados reais (Excel, CSV)
❌ Arquivos de configuração com secrets (.env, config.yml)
❌ Dumps de banco de dados
❌ Logs de aplicação com dados de usuários
❌ Screenshots com dados identificáveis

Alternativa:

✅ Criar documentos de teste com dados fictícios
✅ Usar ferramentas de geração de dados fake
✅ Remover dados sensíveis antes de compartilhar
✅ Usar apenas estruturas/esquemas sem dados

2.3. Ferramentas Proibidas

2.3.1. Ferramentas NÃO Aprovadas

Ferramenta	Razão da Proibição	Alternativa Aprovada
Replit AI	Política de privacidade inadequada	GitHub Copilot
Amazon CodeWhisperer	Não auditado internamente	GitHub Copilot
Codeium	Preocupações com retenção de dados	Tabnine (self-hosted)
Ferramentas desconhecidas	Não avaliadas por Security	Consultar lista aprovada

Uso de ferramenta não aprovada = Violação grave

2.4. Cenários de Violação Comum

2.4.1. Caso 1: Upload de Arquivo com Dados de Clientes

Situação: Desenvolvedor fez upload de arquivo CSV com lista de clientes para perguntar "como processar este CSV em PHP?"

Violação:

Exposição de nomes, emails e telefones de clientes reais
Violação LGPD Art. 46 (transferência internacional de dados)
Potencial multa: Art. 52, II (2% do faturamento)

Consequência:

Suspensão imediata
Notificação à ANPD
Possível rescisão

Como Evitar:

Criar CSV de teste com dados fake
Usar apenas estrutura: headers e 2-3 linhas com dados fictícios
Validar ANTES de compartilhar

2.4.2. Caso 2: Prompt com Credenciais de Banco

Situação: Desenvolvedor pediu "por que esta conexão está falhando?" e colou string de conexão com user/password

Violação:

Exposição de credenciais de produção
Risco de acesso não-autorizado ao banco
Violação de política de segurança

Consequência:

Rotação imediata de credenciais (custo + downtime)
Suspensão de 90 dias
Relatório de incidente de segurança

Como Evitar:

Remover credenciais antes de compartilhar
Usar variáveis de ambiente em exemplos
Descrever erro sem colar código sensível

2.4.3. Caso 3: Geração de Sistema Completo Sem Revisão

Situação: Desenvolvedor pediu "crie um sistema de gestão de pedidos completo" e comitou código sem revisão

Violação:

"Fucking code" (sistema complexo gerado em massa)
Falta de code review
Código em produção sem testes

Consequência:

Rollback imediato
Suspensão de 30 dias
Retrabalho completo necessário

Como Evitar:

Dividir em tarefas pequenas (menos de 50 linhas cada)
Revisar cada tarefa individualmente
Testes para cada componente
Code review obrigatório

2.4.4. Caso 4: Exposição de Lógica de Negócio Proprietária

Situação: Desenvolvedor compartilhou algoritmo proprietário de precificação para refatoração

Violação:

Exposição de trade secret
Risco de propriedade intelectual
Possível violação de NDA

Consequência:

Investigação interna
Possível ação legal
Rescisão por justa causa (dependendo do dano)

Como Evitar:

Abstrair lógica proprietária
Solicitar apenas refatoração de padrões genéricos
Consultar Jurídico antes de compartilhar lógica crítica

2.5. Checklist Antes de Usar IA

SEMPRE verifique antes de enviar prompt:

Se respondeu "não" a qualquer checklist item, NÃO prossiga.

2.6. Processo de Exceção

Quando solicitar exceção:

Uso urgente em projeto normalmente proibido
Ferramenta não aprovada com justificativa forte
Situação emergencial documentada

Processo:

Preencher formulário de exceção detalhado
Análise de risco completa
Plano de mitigação robusto
Aprovações múltiplas (Tech Lead + Security + DPO + CTO)
Documentação formal
Revisão pós-uso obrigatória em 48h

Exceções são RARAS. Não conte com elas.

⚠️ LEMBRE-SE: Uma única violação pode custar seu emprego. Quando em dúvida, NÃO use IA.

1. Quem Pode Usar Vibecoding 3. Proteção de Dados Sensíveis