Plano de ação interativo para iniciar o CRM Munó no servidor
Esta onepage consolida o caminho de implantação do CRM Munó: banco de dados, arquitetura PHP/MySQL, hierarquia Admin > Vendedores > Especificadores, rotas, endpoints, segurança, backups, cron jobs e checklists executáveis por fase.
1. Mapa mental do banco de dados
Modelo relacional recomendado para transformar o estado atual do HTML em uma base única, compartilhada, auditável e preparada para integrações.
2. Mapa mental da arquitetura do projeto
Estrutura proposta para rodar bem em hospedagem compartilhada, separando pasta pública, código da aplicação, configurações, storage, APIs e integrações futuras.
3. Principais dados que precisam virar banco
Equivalência entre o estado atual do HTML/JavaScript e as tabelas recomendadas no MySQL.
| Entidade atual | Origem no HTML | Destino recomendado | Decisão | Observação técnica |
|---|
4. Dados estáticos, configurações e regras comerciais
Nem tudo precisa virar tabela no primeiro ciclo. O critério principal é: se muda com frequência ou é regra de negócio, deve ir para banco.
5. Endpoints PHP sugeridos
APIs pequenas, previsíveis e compatíveis com JavaScript puro via fetch. O endpoint /api/bootstrap carrega o estado inicial da interface.
| Módulo | Endpoints | Responsabilidade |
|---|
6. Migração do HTML para PHP/MySQL sem refazer tudo
A estratégia é preservar a identidade visual e o comportamento atual, mas remover o estado persistente do navegador e centralizar no banco.
Antes
Um HTML grande, estado global S = {...}, produtos em array JS, persistência por localStorage e exportação JSON como backup principal.
Depois
index.php, componentes PHP, CSS/JS separados, dados carregados via fetch('/api/...'), produtos no MySQL e backup SQL.
Front-end
Continuar com JavaScript puro. Criar api.js como camada única de comunicação com backend.
Operação
Integrações e backups por scripts cron. Cada execução deve gravar em integracao_logs para auditoria.
7. Hierarquia de usuários e regra de acesso
A hierarquia precisa nascer no banco e no backend. O JavaScript pode esconder botões, mas a proteção real deve estar nas consultas SQL e nos controllers PHP.
Regra central de escopo
Admin vê tudo. Vendedor vê apenas registros com vendedor_id da própria carteira. Especificador vê apenas dados vinculados ao próprio arquiteto_id e liberados para o portal.
Decisão estrutural
O Especificador não deve acessar o CRM interno com botões escondidos. Ele deve ter um portal próprio, com rotas, consultas e permissões separadas.
Matriz de permissões inicial
Use esta matriz como referência para implementar config/permissions.php e validar cada endpoint no backend.
| Módulo / ação | Admin | Vendedor | Especificador | Observação |
|---|
8. Plano de ação detalhado com checklists
Execução sugerida para transformar o HTML atual em aplicação PHP/MySQL real. A ordem evita retrabalho: primeiro servidor, banco, login e permissões; depois telas, funil, orçamento, eventos e Círculo Munó.
9. Preparação da Hostinger e estrutura do servidor
Checklist operacional para criar o subdomínio, banco, SSL, estrutura de pastas, proteção de diretórios e primeiro teste de conexão.
Estrutura recomendada de pastas
Quando possível, mantenha app, config, database e storage fora da raiz pública.
crm-muno/
public_html/
index.php
.htaccess
assets/
css/
js/
img/
uploads/
imports/
temp/
app/
Core/
Controllers/
Models/
Services/
Views/
config/
app.php
database.php
permissions.php
lookups.php
database/
migrations/
seeds/
storage/
logs/
backups/
cache/.htaccess base
Protege diretórios sensíveis e direciona rotas amigáveis para index.php.
Options -Indexes
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RedirectMatch 403 ^/app/
RedirectMatch 403 ^/config/
RedirectMatch 403 ^/database/
RedirectMatch 403 ^/storage/
<FilesMatch "(\.env|composer\.json|composer\.lock|\.sql|\.log)$">
Require all denied
</FilesMatch>
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [QSA,L]10. Banco de dados, migrations e seeds
Sequência de criação do banco para evitar dependências quebradas. Primeiro usuários e vendedores; depois rede comercial; depois funil, histórico, orçamentos, eventos, Círculo e logs.
| Ordem | Arquivo | Cria | Checklist técnico |
|---|
Campos mínimos da tabela usuarios
A tabela de usuários deve permitir conta Admin, conta de vendedor e conta de especificador vinculada ao cadastro de arquiteto.
usuarios
- id
- nome
- email UNIQUE
- senha_hash
- papel ENUM('admin','vendedor','especificador')
- vendedor_id NULL
- arquiteto_id NULL
- ativo
- primeiro_acesso
- ultimo_login_em
- criado_em
- atualizado_em
- deletado_em11. Segurança, backup, cron jobs e operação
Itens obrigatórios para não transformar o CRM em uma aplicação frágil: sessão segura, prepared statements, backups, logs e rotinas agendadas.
Rotinas cron futuras
cron/backup_diario.php
cron/sync_tiny.php
cron/sync_rdstation.php
cron/sync_goaff.php
cron/recalcular_circulo.php
cron/limpar_imports_antigos.php
Retenção de backup sugerida
Diários: manter últimos 7 Semanais: manter últimos 4 Mensais: manter últimos 3 Antes de importação grande: gerar backup manual Antes de mudança estrutural: gerar backup SQL + cópia dos arquivos
12. Critérios de pronto por módulo
Use estes critérios como trava de qualidade. Um módulo só deve avançar quando os testes básicos, permissões e persistência estiverem corretos.