INSTRUÇÕES GERAIS DE DESENVOLVIMENTO
REGISTROHUB — LARAVEL 12 + PHP 8.4 + POSTGRESQL + EVOLUTION API

Documento: roteiro técnico geral para desenvolvimento
Objetivo: criar uma base clara para Codex/desenvolvedores fragmentarem o projeto em módulos menores
Stack principal: Laravel 12, PHP 8.4, PostgreSQL, Redis, Docker Compose, Evolution API, OpenAI API, Stripe/Pix, Storage S3 compatível
Contexto: já existe layout base para espelhar

============================================================
1. DECISÃO TÉCNICA PRINCIPAL
============================================================

A stack recomendada para o RegistroHub é:

- Backend: Laravel 12
- Linguagem: PHP 8.4
- Banco de dados principal: PostgreSQL
- Cache/fila/session: Redis
- Queue dashboard: Laravel Horizon
- Frontend: Blade + Livewire 3 ou Inertia.js + Vue 3
- Build frontend: Vite
- Containerização: Docker Compose
- Webserver: Nginx
- Process manager: Supervisor
- WhatsApp: Evolution API em serviço/container separado
- IA: OpenAI API
- Pagamentos: Stripe + gateway Pix brasileiro se necessário
- Storage: S3 compatível, como AWS S3, Wasabi, Backblaze B2 ou MinIO
- Observabilidade: logs estruturados + Sentry opcional
- Deploy: Docker Compose no início; Kubernetes apenas se o projeto crescer muito

============================================================
2. BANCO DE DADOS ESCOLHIDO
============================================================

Banco escolhido: POSTGRESQL.

Motivo da escolha:

1. O RegistroHub terá multi-tenant, auditoria, logs, metadados de IA, respostas JSON, relatórios, eventos, webhooks, configurações por tenant, certificado autoral e busca por dados semi-estruturados.

2. PostgreSQL é mais indicado que MySQL para este projeto porque oferece excelente suporte a JSONB, índices avançados, consultas complexas, integridade relacional forte, schemas, views, partial indexes, full-text search e bom desempenho em sistemas SaaS complexos.

3. O módulo RegistroHub Autoral terá metadados variados por tipo de criação, certificado, hash, validação pública e logs. JSONB será útil para armazenar dados dinâmicos sem perder capacidade de consulta.

4. Para relatórios por tenant, unidade, parceiro, plano, comissões, carteira e monitoramento, PostgreSQL tende a dar mais flexibilidade.

5. A Evolution API pode rodar no mesmo servidor, mas deve ter banco separado ou schema separado. Recomendação: banco PostgreSQL separado para Evolution API, para não misturar dados da aplicação principal.

Decisão final:

- registrohub_db: banco principal do RegistroHub
- evolution_db: banco separado da Evolution API
- redis: cache, filas e sessão
- storage externo: documentos, certificados, arquivos originais e logos

============================================================
3. ESTRUTURA DE SERVIDOR RECOMENDADA
============================================================

O sistema pode rodar no mesmo servidor da Evolution API, mas tudo deve ficar isolado por containers.

Serviços recomendados no Docker Compose:

1. app
   - Laravel 12 + PHP 8.4 FPM
   - Código do RegistroHub

2. nginx
   - Proxy HTTP/HTTPS para Laravel
   - Servir assets públicos
   - Redirecionar domínio principal

3. postgres
   - Banco do RegistroHub
   - Não expor publicamente

4. postgres_evolution
   - Banco separado para Evolution API
   - Não expor publicamente

5. redis
   - Cache, sessão, filas, rate limiting

6. horizon
   - Worker de filas Laravel Horizon

7. scheduler
   - Laravel Scheduler rodando a cada minuto

8. evolution_api
   - Serviço da Evolution API
   - Conectado ao postgres_evolution
   - Acesso interno pelo Laravel

9. backup
   - Rotina de backup opcional
   - Dump do PostgreSQL
   - Backup de storage se usar MinIO/local

10. minio opcional
   - Apenas para ambiente de desenvolvimento ou VPS sem S3 externo

Recomendação:
Para produção, preferir storage S3 externo em vez de guardar documentos no disco local do servidor.

============================================================
4. FRONTEND RECOMENDADO
============================================================

Como já existe layout base HTML para espelhar, existem duas opções boas:

OPÇÃO A — Blade + Livewire 3
Melhor para velocidade no Laravel e facilidade com Codex.
Vantagens:
- Menos complexidade.
- Muito produtivo para dashboards, formulários e painéis.
- Menos necessidade de API interna.
- Fácil para CRUDs, permissões e modais.
- Ideal para SuperAdmin, Tenant e Cliente Final.

OPÇÃO B — Inertia.js + Vue 3
Melhor se quiser experiência mais SPA e componentes mais avançados.
Vantagens:
- Interface moderna.
- Componentes reutilizáveis.
- Melhor para telas ricas e interativas.
- Mais complexo que Livewire.

Escolha recomendada para MVP:
Blade + Livewire 3 + Alpine.js + Tailwind ou CSS do layout base.

Motivo:
Codex/desenvolvedores conseguem evoluir com menos risco, usando padrões Laravel puros. O layout base HTML pode ser quebrado em componentes Blade/Livewire.

============================================================
5. TECNOLOGIAS ADICIONAIS RECOMENDADAS
============================================================

Pacotes e tecnologias recomendadas:

1. Autenticação
- Laravel Breeze ou Laravel Fortify
- 2FA para SuperAdmin
- Magic link para cliente final, se possível

2. Permissões
- spatie/laravel-permission

3. Multi-tenant
- Implementação própria com tenant_id no MVP
- Middleware TenantResolver
- Policies e Global Scopes
- Evitar complexidade inicial de banco por tenant

4. Auditoria
- owen-it/laravel-auditing ou implementação própria
- Recomendado: implementação própria para domínio crítico

5. Filas
- Redis
- Laravel Horizon

6. Pagamento
- Laravel Cashier para Stripe, se usar Stripe com assinaturas
- Gateway Pix brasileiro em serviço separado: Asaas, Mercado Pago, Pagar.me ou outro
- Webhooks idempotentes

7. Storage
- Laravel Filesystem S3
- Disks separados:
  - logos
  - documents
  - copyright_originals
  - certificates
  - reports

8. PDFs
- spatie/browsershot ou dompdf/snappy
- Para certificado autoral, gerar PDF com template HTML próprio

9. Excel/CSV
- maatwebsite/excel para relatórios e exportações

10. Logs/Erros
- Sentry opcional
- Logs em JSON
- Tabela webhook_logs
- Tabela api_usage_logs

11. IA
- OpenAI API
- Criar AiGatewayService para isolar provedor
- Prompts versionados no banco

12. QR Code
- simple-qrcode ou pacote equivalente
- Usado para validação pública de certificados

13. Hash de arquivos
- hash_file('sha256', $path)
- Registrar SHA-256 do arquivo original

14. Criptografia
- Criptografar dados sensíveis quando necessário
- Links temporários para downloads

15. Testes
- Pest PHP
- Feature tests para multi-tenant
- Tests para permissões
- Tests para webhooks
- Tests para consumo de créditos

============================================================
6. COMO O CODEX DEVE TRABALHAR MELHOR
============================================================

Para o Codex render melhor, o projeto deve ser organizado em módulos pequenos e instruções diretas.

Boas práticas:

1. Não pedir para ele criar tudo de uma vez.
2. Dividir por domínio:
   - Core SaaS
   - Tenants
   - Usuários e permissões
   - Clientes
   - Marcas
   - Autoral
   - Financeiro
   - Helpdesk
   - IA
   - Evolution API
   - Monitoramento
3. Cada tarefa deve ter:
   - objetivo
   - arquivos esperados
   - tabelas envolvidas
   - regras de negócio
   - critérios de aceite
4. Criar testes junto com cada módulo.
5. Manter nomes consistentes de tabelas, services e enums.
6. Evitar lógica de negócio em controllers.
7. Usar Services, Actions, Jobs, Policies e Form Requests.
8. Fazer commits pequenos por módulo.
9. Manter sandbox/permissões de execução controladas.

Padrão de arquitetura Laravel recomendado:

app/
  Actions/
  Console/
  Enums/
  Events/
  Http/
    Controllers/
    Livewire/
    Middleware/
    Requests/
  Jobs/
  Models/
  Notifications/
  Policies/
  Services/
  Support/

domains opcionais:
app/Domains/
  Tenancy/
  Trademark/
  Copyright/
  Billing/
  Helpdesk/
  AI/
  WhatsApp/
  Monitoring/

Escolha recomendada:
Usar app/Domains para manter o projeto limpo e escalável.

============================================================
7. DOMÍNIOS DO SISTEMA
============================================================

O RegistroHub terá estes domínios principais:

1. Core SaaS
- Tenants
- Planos
- Configurações
- White label
- Módulos ativos

2. Usuários e Permissões
- SuperAdmin
- Operador
- Suporte
- Tenant Admin
- Rede Master
- Unidade/Franqueado
- Parceiro B2B
- Cliente Final

3. Cadastro e Qualificação
- Trial
- Intenção do lead
- Cliente final
- Parceiro B2B
- Rede/franqueadora
- Lead consultivo
- Score e plano recomendado

4. RegistroHub Marcas
- Cadastro de marca
- Documentos
- Pré-análise
- Busca de anterioridade
- Relatório IA
- Revisão humana
- GRU/protocolo assistido
- Monitoramento

5. RegistroHub Autoral
- Upload de criação
- Hash SHA-256
- Certificado PDF
- QR Code
- Validação pública
- Backup
- Pastas e projetos
- Créditos mensais

6. Financeiro
- Checkout direto
- Carteira operacional
- Rede centralizada
- Créditos
- Planos
- Assinaturas
- Comissões
- Setup
- Repasses

7. Helpdesk
- Chamados por tenant
- Chamados por unidade
- Chamados por cliente/marca/certificado
- SLA
- Categorias
- Prioridade
- Atribuição

8. IA Copiloto
- Prompts versionados
- Análise de marca
- Classificação de criação
- Mensagens automáticas
- Resumo para admin
- Resumo para cliente

9. WhatsApp / Evolution API
- Templates
- Envio por fila
- Histórico de mensagens
- Status de entrega
- Reenvio
- Rate limiting

10. Monitoramento
- Processo INPI
- Marcas semelhantes
- Créditos acabando
- Assinaturas vencidas
- Validações de certificado

============================================================
8. MODELO MULTI-TENANT
============================================================

Modelo recomendado para MVP:

- Banco único
- tenant_id em tabelas operacionais
- unit_id para redes/franquias
- customer_id para cliente final
- Global Scopes quando fizer sentido
- Policies obrigatórias
- Middleware TenantResolver
- SuperAdmin com bypass auditado

Regras:

1. Cliente final não cria tenant.
2. Parceiro B2B aprovado cria tenant simples.
3. Rede/franqueadora aprovada cria tenant master.
4. Franqueados/unidades ficam dentro do tenant da rede.
5. SuperAdmin vê todos.
6. Tenant Admin vê apenas seu tenant.
7. Unidade vê apenas seus clientes.
8. Cliente final vê apenas seus próprios dados.
9. White label é configuração do tenant, não aplicação separada.

Tabelas com tenant_id:
- users
- units
- customers
- trademarks
- trademark_requests
- trademark_documents
- copyright_certificates
- copyright_files
- payments
- wallets
- wallet_transactions
- commissions
- helpdesk_tickets
- notifications
- whatsapp_messages
- audit_logs

============================================================
9. MÓDULOS ATIVOS POR TENANT
============================================================

Cada tenant deve poder ativar ou desativar módulos.

Campos recomendados:

tenant_modules:
- marcas
- autoral
- monitoring
- helpdesk
- ai_copilot
- whatsapp
- white_label
- billing_wallet
- billing_checkout
- billing_network_centralized

Exemplo:

Rede de franquia:
- marcas: true
- autoral: true
- monitoring: true
- helpdesk: true
- ai_copilot: true
- white_label: true
- billing_network_centralized: true

Contador pequeno:
- marcas: true
- autoral: false ou true
- monitoring: true
- helpdesk: true
- white_label: false
- billing_checkout: true

Designer/agência:
- marcas: true
- autoral: true
- monitoring: false opcional
- white_label: co_branding opcional
- billing_wallet: true

============================================================
10. REGISTROHUB MARCAS — REGRAS
============================================================

Fluxo:

1. Cadastro da marca
2. Upload da logo e documentos
3. IA sugere tipo de marca e classe
4. API busca marcas semelhantes
5. IA gera relatório preliminar
6. Operador/SuperAdmin revisa
7. Cliente aceita termo de ciência
8. Pagamento é confirmado
9. Processo segue para GRU/protocolo assistido
10. Número do processo é registrado
11. Monitoramento é ativado

Regras:

- Nenhum processo avança sem documentos obrigatórios.
- Risco alto bloqueia o processo.
- IA não promete deferimento.
- Revisão humana obrigatória antes de GRU/protocolo.
- Cliente precisa aceitar termo de ciência.
- Toda mudança de status gera log.
- Todo documento tem controle de acesso.
- Monitoramento só fica ativo com plano, saldo ou contrato.

============================================================
11. REGISTROHUB AUTORAL — REGRAS
============================================================

Fluxo:

1. Cliente/parceiro seleciona RegistroHub Autoral
2. Cria pasta ou projeto
3. Preenche dados da criação
4. Faz upload do arquivo
5. Sistema calcula SHA-256
6. Sistema gera certificado PDF
7. Sistema gera QR Code de validação
8. Sistema salva certificado e arquivo original
9. Sistema consome crédito ou confirma pagamento
10. Certificado fica disponível no painel
11. Validação pública permite conferir dados sem expor o arquivo original

Regras:

- Certificado autoral não substitui registro de marca no INPI.
- O sistema não deve afirmar originalidade universal.
- O arquivo original deve ser preservado.
- Se o arquivo for alterado, o hash muda e será outro certificado.
- A validação pública não deve liberar o arquivo original.
- Todo download do arquivo original gera log.
- Todo certificado deve ter código único.
- Certificados cancelados ou com falha devem preservar histórico.
- Crédito consumido deve gerar extrato.

Dados do certificado:

- certificate_code
- tenant_id
- unit_id
- customer_id
- folder_id
- project_id
- work_title
- work_category
- description
- author_name
- holder_name
- file_hash_sha256
- file_name
- file_size
- file_mime
- issued_at
- status
- certificate_pdf_path
- original_file_path_private
- public_validation_url
- created_by

============================================================
12. FINANCEIRO — MODELOS DE COBRANÇA
============================================================

Modelos principais:

1. Checkout RegistroHub
- Cliente paga direto ao RegistroHub
- Ideal para venda direta e parceiro indicador
- Pode gerar comissão ao parceiro

2. Carteira Operacional
- Parceiro compra saldo ou pacote de créditos
- Consome créditos ao usar serviços
- Ideal para advogados, contadores, designers e agências que cobram seus próprios clientes

3. Rede Centralizada
- Cliente final paga à franqueadora/rede
- Franqueado atua como canal de venda
- RegistroHub cobra taxa operacional da rede
- Franqueado recebe comissão conforme regra da rede

Não implementar pós-pago no MVP.
Pós-pago fica para fase futura, com contrato enterprise e limite de crédito.

Tipos de créditos:

- autoral_certificate
- trademark_pre_analysis
- trademark_search
- trademark_full_report
- trademark_process
- trademark_monitoring_month
- whatsapp_message
- ai_analysis

Regras:

- Processo não avança sem pagamento ou saldo.
- SuperAdmin pode liberar exceção com justificativa.
- Comissão só é liberada após pagamento confirmado.
- Carteira deve ter extrato.
- Toda movimentação financeira gera log.
- Inadimplência pode pausar monitoramento.
- Não apagar histórico de clientes inadimplentes.

============================================================
13. EVOLUTION API NO MESMO SERVIDOR
============================================================

A Evolution API deve rodar no mesmo servidor, mas isolada.

Regras:

- Container próprio.
- Banco próprio: evolution_db.
- Não misturar tabelas da Evolution com RegistroHub.
- Laravel deve falar com Evolution por HTTP interno.
- Criar EvolutionApiService no Laravel.
- Envio sempre via fila.
- Registrar todas as mensagens em whatsapp_messages.
- Controlar falha, retry e status.
- Não enviar mensagens em massa sem rate limit.
- Cada tenant pode ter:
  - instância compartilhada RegistroHub
  - instância própria do tenant, em planos superiores
  - instância própria da rede/franqueadora em white label

Campos para instância:

- tenant_id
- instance_name
- provider
- base_url
- api_key_encrypted
- status
- default_sender
- webhook_secret
- last_connection_at

Eventos de WhatsApp:

- welcome
- document_pending
- analysis_finished
- risk_found
- payment_pending
- payment_confirmed
- protocol_created
- monitoring_alert
- opposition_found
- certificate_issued
- credit_low
- subscription_due
- helpdesk_reply

============================================================
14. HELPDesk
============================================================

O RegistroHub terá helpdesk próprio.

Motivo:
Brivox será CRM e bot comercial. O helpdesk do RegistroHub é operacional.

Entidades:

- helpdesk_tickets
- helpdesk_messages
- helpdesk_categories
- support_slas
- ticket_attachments

Categorias:

- suporte técnico
- financeiro
- documentos
- marca
- autoral
- IA
- WhatsApp
- monitoramento
- oposição/exigência
- white label
- bug
- solicitação de melhoria

Regras:

- Tenant abre chamado para SuperAdmin.
- Unidade pode abrir chamado para tenant master ou SuperAdmin, conforme configuração.
- Cliente final pode abrir chamado simples.
- Chamado pode ser ligado a cliente, marca, certificado, pagamento ou tenant.
- SLA por prioridade.
- Toda resposta gera notificação.
- Chamado crítico pode criar tarefa interna.

============================================================
15. IA COPILOTO
============================================================

Criar AiGatewayService para isolar OpenAI.

Módulos de IA:

1. Marca
- Sugere classe
- Analisa risco
- Resume busca
- Gera relatório para cliente
- Gera relatório para admin

2. Autoral
- Sugere categoria da criação
- Ajuda na descrição
- Gera resumo do certificado
- Explica limite jurídico

3. Atendimento
- Mensagens curtas para WhatsApp
- Follow-up
- Resposta padrão de pendência
- Explicação simples ao cliente

4. SuperAdmin
- Resumo de risco
- Resumo de incidente
- Sugestão de próxima ação

Regras:

- Prompts versionados.
- Saída estruturada em JSON para decisões.
- Não deixar IA decidir sozinha.
- Nunca prometer deferimento.
- Nunca dizer que certificado autoral garante propriedade absoluta.
- Toda análise IA crítica deve ficar salva.

Tabelas:

- ai_prompts
- ai_prompt_versions
- ai_reports
- ai_messages
- ai_usage_logs

============================================================
16. SEGURANÇA E LGPD
============================================================

Regras:

- 2FA obrigatório para SuperAdmin.
- Storage privado para documentos e arquivos originais.
- URLs temporárias para download.
- Criptografar chaves de API.
- Logs de download.
- Logs de acesso.
- Logs de alteração.
- Controle de permissão por policy.
- Não expor arquivo original em validação pública.
- Cliente deve aceitar termos.
- Termo de ciência para marca.
- Termo de ciência para certificado autoral.
- Política de privacidade.
- Contrato de parceiro.
- Contrato de rede.
- Contrato de white label.
- Contrato com advogado parceiro, se houver.

============================================================
17. STATUS PRINCIPAIS
============================================================

Status de tenant:
- pending_approval
- trial_active
- active
- suspended
- cancelled

Status de marca:
- trademark_new
- awaiting_documents
- documents_submitted
- ai_pre_analysis
- search_running
- report_generated
- awaiting_human_review
- changes_requested
- risk_blocked
- approved_by_superadmin
- awaiting_payment
- approved_for_gru
- gru_issued
- gru_paid
- awaiting_protocol
- protocolled
- in_monitoring
- requirement_published
- opposition_found
- incident_open
- deferred
- rejected
- granted
- archived
- completed

Status autoral:
- copyright_draft
- awaiting_file_upload
- file_uploaded
- hash_generated
- awaiting_payment_or_credit
- certificate_generating
- certificate_issued
- certificate_failed
- certificate_cancelled
- certificate_validated

Status financeiro:
- pending
- paid
- failed
- refunded
- cancelled
- overdue
- manually_released

Status helpdesk:
- open
- waiting_customer
- waiting_internal
- in_progress
- resolved
- closed
- escalated

============================================================
18. MODELAGEM DE TABELAS
============================================================

CORE:
- tenants
- tenant_settings
- tenant_modules
- white_label_settings
- units
- users
- roles
- permissions
- customers
- leads
- partner_applications
- audit_logs

MARCAS:
- trademarks
- trademark_requests
- trademark_documents
- trademark_searches
- trademark_search_results
- ai_reports
- review_logs
- process_status_history
- incidents
- incident_actions
- monitoring_rules
- monitoring_runs
- monitoring_results

AUTORAL:
- copyright_certificates
- copyright_files
- copyright_folders
- copyright_projects
- copyright_authors
- copyright_hashes
- copyright_validation_logs
- copyright_credit_usage
- copyright_certificate_templates

FINANCEIRO:
- plans
- subscriptions
- payments
- invoices
- wallets
- wallet_transactions
- service_credits
- credit_packages
- commission_rules
- commissions
- setup_fees

SUPORTE:
- helpdesk_tickets
- helpdesk_messages
- helpdesk_categories
- support_slas
- tasks

COMUNICAÇÃO:
- notifications
- whatsapp_instances
- whatsapp_messages
- email_messages
- message_templates

INTEGRAÇÕES:
- api_credentials
- api_usage_logs
- webhook_logs
- evolution_events
- payment_webhooks

============================================================
19. ESTRUTURA DE CÓDIGO
============================================================

Usar app/Domains.

Estrutura sugerida:

app/Domains/Tenancy/
  Actions/
  Models/
  Services/
  Policies/
  Enums/

app/Domains/Trademark/
  Actions/
  Models/
  Services/
  Jobs/
  Policies/
  Enums/

app/Domains/Copyright/
  Actions/
  Models/
  Services/
  Jobs/
  Policies/
  Enums/

app/Domains/Billing/
  Actions/
  Models/
  Services/
  Jobs/
  Enums/

app/Domains/Helpdesk/
  Actions/
  Models/
  Services/
  Notifications/
  Enums/

app/Domains/AI/
  Services/
  DTOs/
  Jobs/

app/Domains/WhatsApp/
  Services/
  Jobs/
  DTOs/

app/Domains/Monitoring/
  Services/
  Jobs/
  Actions/

app/Http/Livewire/
  SuperAdmin/
  Tenant/
  Customer/
  Auth/

resources/views/
  layouts/
  components/
  superadmin/
  tenant/
  customer/
  auth/

============================================================
20. PASSO A PASSO GERAL DO DESENVOLVIMENTO
============================================================

FASE 0 — Preparação do repositório
1. Criar repositório Git.
2. Criar projeto Laravel 12.
3. Configurar PHP 8.4.
4. Configurar Docker Compose.
5. Configurar PostgreSQL.
6. Configurar Redis.
7. Configurar Nginx.
8. Configurar Horizon.
9. Configurar Scheduler.
10. Configurar Evolution API em container separado.
11. Configurar ambiente .env.example.
12. Configurar padrões de lint/testes.

FASE 1 — Base SaaS
1. Criar tenants.
2. Criar tenant_settings.
3. Criar tenant_modules.
4. Criar units.
5. Criar users.
6. Criar roles e permissions.
7. Criar middleware TenantResolver.
8. Criar policies.
9. Criar SuperAdmin dashboard base.
10. Criar Tenant dashboard base.
11. Integrar layout base.

FASE 2 — Cadastro e qualificação
1. Criar tela de cadastro trial.
2. Criar tipos de intenção.
3. Criar leads.
4. Criar partner_applications.
5. Criar fluxo de aprovação.
6. Criar geração de tenant quando aprovado.
7. Criar criação de cliente final quando for cliente direto.
8. Criar score de qualificação.

FASE 3 — RegistroHub Marcas
1. Criar customers.
2. Criar trademarks.
3. Criar trademark_requests.
4. Criar upload de documentos.
5. Criar checklist.
6. Criar status.
7. Criar tela do cliente final.
8. Criar tela do parceiro.
9. Criar tela de revisão SuperAdmin.
10. Criar histórico de status.

FASE 4 — IA e busca
1. Criar AiGatewayService.
2. Criar prompts versionados.
3. Criar integração com API de busca de marcas.
4. Criar trademark_searches.
5. Criar trademark_search_results.
6. Criar relatório IA.
7. Criar bloqueio por risco alto.
8. Criar revisão humana.

FASE 5 — Financeiro
1. Criar planos.
2. Criar pagamentos.
3. Criar carteira operacional.
4. Criar créditos de serviço.
5. Criar checkout.
6. Criar Pix/gateway.
7. Criar comissões.
8. Criar extrato.
9. Criar webhooks.
10. Criar bloqueios por pagamento.

FASE 6 — RegistroHub Autoral
1. Criar copyright_folders.
2. Criar copyright_projects.
3. Criar upload de arquivo.
4. Calcular SHA-256.
5. Criar certificado PDF.
6. Criar QR Code.
7. Criar validação pública.
8. Criar consumo de crédito.
9. Criar backup do certificado.
10. Criar backup do arquivo original privado.

FASE 7 — Evolution API
1. Criar whatsapp_instances.
2. Criar EvolutionApiService.
3. Criar templates.
4. Criar fila de envio.
5. Criar histórico.
6. Criar webhook de retorno.
7. Criar retry.
8. Criar rate limit por tenant.

FASE 8 — Helpdesk
1. Criar helpdesk_tickets.
2. Criar helpdesk_messages.
3. Criar categorias.
4. Criar prioridades.
5. Criar SLA.
6. Criar vínculo com cliente, marca e certificado.
7. Criar notificações.
8. Criar painel SuperAdmin de chamados.
9. Criar painel tenant de chamados.

FASE 9 — Monitoramento
1. Criar regras de monitoramento.
2. Criar scheduler.
3. Criar jobs.
4. Criar monitoramento de processo.
5. Criar monitoramento de marcas semelhantes.
6. Criar alertas.
7. Criar resumo IA.
8. Criar notificações WhatsApp/e-mail.
9. Criar relatório por tenant.

FASE 10 — White Label
1. Criar white_label_settings.
2. Criar logo, cor, nome e subdomínio.
3. Criar co-branding.
4. Criar white label completo.
5. Criar assinatura de mensagens.
6. Criar domínio próprio em fase avançada.

FASE 11 — Auditoria, LGPD e estabilidade
1. Criar audit_logs.
2. Criar logs de download.
3. Criar logs de certificados.
4. Criar consentimentos.
5. Criar termos.
6. Criar política de privacidade.
7. Criar backup.
8. Criar testes.
9. Criar documentação.
10. Criar seeders e dados de demonstração.

============================================================
21. PRIMEIRO PROMPT PARA O CODEX
============================================================

Use este prompt inicial para o Codex:

"Você é um engenheiro sênior Laravel. Vamos construir o RegistroHub em Laravel 12 com PHP 8.4, PostgreSQL, Redis, Docker Compose, Livewire 3, Horizon e Evolution API em container separado. O projeto será SaaS multi-tenant com tenant_id, SuperAdmin, tenants, units, clientes finais, RegistroHub Marcas, RegistroHub Autoral, financeiro, helpdesk, IA e WhatsApp. Já existe layout HTML base para espelhar. Primeiro, crie a estrutura inicial do projeto, Docker Compose, configurações de PostgreSQL/Redis/Nginx, autenticação base, roles/permissões, tenants, middleware TenantResolver e dashboard base SuperAdmin/Tenant usando o layout informado. Não implemente todos os módulos ainda. Crie migrations, models, policies, seeders e testes básicos de isolamento multi-tenant."

Critérios de aceite do primeiro passo:
- Projeto sobe com docker compose up -d.
- Laravel responde.
- PostgreSQL conectado.
- Redis conectado.
- Horizon acessível.
- Login funcional.
- SuperAdmin criado via seeder.
- Tenant de demonstração criado.
- Usuário tenant admin criado.
- Middleware de tenant funcionando.
- Usuário de um tenant não acessa dados de outro.
- Layout base aplicado ao dashboard.

============================================================
22. OBSERVAÇÕES FINAIS
============================================================

1. Não construir tudo de uma vez.
2. Começar por base SaaS, tenant, permissões e layout.
3. Depois construir Marcas.
4. Depois financeiro.
5. Depois Autoral.
6. Depois Evolution API.
7. Depois Helpdesk.
8. Depois Monitoramento.
9. Depois White Label avançado.
10. Sempre criar testes para isolamento e permissões.

Diretriz final:
O RegistroHub deve ser simples para vender, seguro para operar e modular para escalar.
