# Prompt para novo projecto — SUPER Comercial

Quero iniciar um novo projecto independente chamado **SUPER Comercial**, destinado à área comercial da **SUPER Seguros**, Angola.

## 1. Princípio de arquitectura
O SUPER Comercial deve ser uma aplicação própria, independente do **SUPER Gestão de Capital Humano (SUPER GCH)**. Não quero transformar o GCH num CRM. O novo sistema terá aplicação, base de dados, permissões, workflows, auditoria, PWA, Centro de Actualizações e ciclo de versões próprios.

Endereço previsto:

`https://comercial.super.co.ao`

O sistema deve seguir a identidade visual institucional da SUPER Seguros e a experiência das demais aplicações SUPER: layout responsivo, mobile-first, PWA, sidebar institucional, pesquisa global, notificações, Web Push quando aplicável, PT-AO, selects pesquisáveis, auditoria, segurança, diagnóstico e actualizações versionadas.

## 2. Autenticação e SSO com o SUPER GCH
O **SUPER GCH em `https://rh.super.co.ao` deve ser o Provedor de Identidade institucional**.

O SUPER Comercial deve funcionar como cliente SSO do mecanismo institucional já existente no GCH, seguindo o mesmo princípio usado pelas aplicações SUPER Secretária, Compliance, Auditor Interno e outras.

Pretendo:
- Authorization Code com PKCE;
- Client ID e Client Secret próprios do SUPER Comercial;
- Redirect URI restrita ao domínio `comercial.super.co.ao`;
- Post Logout Redirect URI;
- backchannel logout assinado, para terminar a sessão do SUPER Comercial quando a sessão institucional for revogada no GCH;
- validação de `state`, `nonce`, PKCE, emissor, audiência e expiração;
- MFA exigido no GCH quando a política institucional o determinar;
- criação/actualização local do utilizador apenas a partir dos claims autorizados;
- sessão local segura, mas sem guardar palavra-passe do trabalhador;
- apenas um Super Administrador Técnico local de emergência, devidamente governado;
- revogação de acesso no GCH deve impedir novo login e terminar sessões federadas activas.

O GCH fornece apenas identidade profissional mínima: `sub`, nome, nome preferido, e-mail profissional, telefone profissional quando autorizado, employee/person id técnico, cargo, unidade orgânica e estado de acesso. **Não devem ser transferidos salário, assiduidade, disciplina, saúde, documentos pessoais, benefícios ou outros dados de Capital Humano.**

Os papéis comerciais devem ser geridos **no SUPER Comercial**, não herdados cegamente dos papéis do GCH.

## 3. Perfis iniciais no SUPER Comercial
Criar RBAC próprio, pelo menos com:
- Super Administrador Técnico;
- Director Comercial;
- Gestor/Supervisor Comercial;
- Comercial;
- Marketing;
- Administração/Executivo apenas para dashboards quando autorizado;
- Consulta/Auditoria quando necessário.

Separar permissões como:
- `crm.leads.view` / `crm.leads.manage`;
- `crm.opportunities.view` / `crm.opportunities.manage`;
- `crm.pipeline.manage`;
- `crm.activities.manage`;
- `crm.assignments.manage`;
- `crm.campaigns.manage`;
- `crm.forecast.view`;
- `crm.reports.view` / `crm.reports.export`;
- `crm.settings.manage`;
- `crm.integrations.manage`;
- `crm.audit.view`.

Aplicar segregação de funções e limitar carteiras/equipas quando aplicável.

## 4. Objectivo funcional
O SUPER Comercial deve ser o **CRM Institucional da SUPER Seguros**.

Quero que o Director Comercial consiga gerir a operação diária num cockpit único, mas que cada registo continue rastreável e governado.

Fluxo central inicial:

`Lead → Qualificação → Contacto → Levantamento de necessidade → Cotação → Negociação → Ganho / Perdido`

Os estados devem ser configuráveis sem permitir que se perca a semântica histórica.

## 5. Leads e contactos
Criar:
- Pessoas/Contactos;
- Empresas/Organizações;
- Leads;
- origem do lead;
- produto/ramo de interesse;
- canal preferido;
- consentimento/contactabilidade;
- província/localidade quando necessário;
- responsável comercial;
- equipa/carteira;
- prioridade;
- score de qualificação explicável;
- estado;
- próxima acção;
- SLA;
- histórico de alterações.

Implementar detecção de duplicados por telefone/e-mail e mecanismos de fusão governada, sem apagar a rastreabilidade.

## 6. Oportunidades e pipeline
Cada oportunidade deve ter:
- referência institucional `OPP-*`;
- cliente/contacto/empresa;
- produto/ramo;
- origem;
- campanha associada;
- Embaixador/trabalhador de origem quando aplicável;
- responsável;
- equipa;
- fase do pipeline;
- valor/prémio potencial quando permitido;
- probabilidade;
- data estimada de fecho;
- próxima actividade;
- motivo de ganho/perda;
- notas comerciais;
- anexos/evidências autorizadas;
- auditoria completa.

Criar Kanban e vista tabular, ambos responsivos.

## 7. Actividades e linha temporal 360
A ficha do cliente/oportunidade deve ter uma timeline única com:
- chamada;
- reunião;
- e-mail;
- WhatsApp apenas como registo/referência se não existir integração oficial;
- nota;
- tarefa;
- follow-up;
- envio/recepção de documento;
- cotação;
- mudança de fase;
- atribuição/retribuição;
- SLA e escalonamento.

Nunca inventar integrações externas que não estejam configuradas.

## 8. Agenda e tarefas comerciais
Implementar agenda comercial com:
- tarefas pessoais;
- follow-ups;
- reuniões;
- prazos;
- lembretes;
- atrasados;
- vencem hoje;
- próximos 7 dias;
- distribuição por responsável/equipa;
- calendário;
- notificações in-app/Web Push quando configuradas.

## 9. SLA comercial
Criar regras configuráveis, por exemplo:
- novo lead deve ser contactado em X horas;
- follow-up após cotação em X dias;
- oportunidade sem actividade por X dias gera alerta;
- lead sem responsável gera alerta;
- escalonamento ao supervisor/Director quando ultrapassa o SLA.

O SLA deve ser explicável e auditável.

## 10. Integração com SUPER Embaixador do GCH
O SUPER Embaixador continuará no GCH, mas **o tratamento comercial deve passar para o SUPER Comercial**.

Criar um conector GCH ↔ SUPER Comercial sem acesso directo à base de dados de nenhum dos sistemas.

O GCH deve enviar apenas a informação necessária de uma indicação:
- referência da indicação;
- nome/contacto fornecido pelo potencial cliente;
- produto de interesse;
- consentimento/contactabilidade;
- observação autorizada;
- identificador institucional do Embaixador de origem;
- campanha/origem quando aplicável;
- timestamps e idempotency key.

O SUPER Comercial responde ao GCH apenas com estado mínimo, por exemplo:

`Recebido → Em contacto → Cotado → Convertido / Não convertido`

O trabalhador no GCH não deve ver notas internas, valores confidenciais, documentos do cliente nem estratégia comercial. Deve ver apenas o estado apropriado da sua indicação.

Usar API HTTPS assinada/HMAC ou outro mecanismo institucional seguro já adoptado no ecossistema SUPER, com:
- segredo cifrado;
- nonce/timestamp;
- idempotência;
- replay protection;
- allowlist de origem quando aplicável;
- logs de integração;
- retries controlados;
- health check;
- sem dependência runtime da base de dados remota.

## 11. Marketing e campanhas
Criar campanhas comerciais com:
- referência `CMP-*`;
- produto;
- segmento;
- período;
- landing page;
- materiais;
- origem/canal;
- links rastreáveis;
- leads gerados;
- oportunidades;
- conversões;
- custo quando informado;
- ROI quando os dados existirem.

Integrar no futuro com o Kit/Campanhas do SUPER Embaixador sem duplicar os ficheiros de forma desgovernada.

## 12. Produtos e catálogo comercial
Criar catálogo de produtos/soluções da SUPER Seguros com informação comercial governada:
- ramo/produto;
- descrição curta;
- público-alvo;
- argumentos-chave;
- documentos aprovados;
- perguntas frequentes;
- estado;
- vigência.

Não implementar motor actuarial ou aceitação de risco nesta primeira fase, salvo integração futura explícita.

## 13. Cotações
Nesta primeira fase, o CRM pode registar a referência/estado da cotação e anexos autorizados.

Preparar arquitectura para futura integração com motores de cotação ou sistemas de apólices, mas **não criar dependência fictícia**.

## 14. Director Comercial — Cockpit
O Director Comercial deve ter um cockpit com:
- novos leads;
- leads por contactar;
- SLA ultrapassado;
- pipeline por fase;
- oportunidades sem actividade;
- previsão de fecho;
- taxa de conversão;
- produtos mais procurados;
- origem dos leads;
- campanhas;
- desempenho agregado por equipa/carteira;
- motivos de perda;
- oportunidades provenientes do SUPER Embaixador;
- tendências e alertas.

Evitar rankings simplistas. Quando houver indicadores individuais, devem ser contextuais, explicáveis e restritos aos perfis autorizados.

## 15. Pesquisa Global
Pesquisar, conforme permissões:
- leads;
- clientes;
- empresas;
- oportunidades;
- campanhas;
- actividades;
- referências;
- tarefas.

Não revelar resultados fora do âmbito/carteira/permissão do utilizador.

## 16. Relatórios e inteligência
Criar relatórios exportáveis para Excel/PDF onde fizer sentido:
- funil;
- conversão;
- origens;
- produtos;
- campanhas;
- SLA;
- actividade;
- carteira;
- previsão;
- perdas.

Garantir filtros por período, equipa, responsável, origem, produto e fase.

## 17. Segurança, privacidade e governação
Requisitos permanentes:
- PHP compatível com o ambiente de produção SUPER;
- PDO/prepared statements;
- CSRF;
- XSS escaping;
- cookies seguros;
- MFA via SSO;
- RBAC;
- controlo por carteira/equipa;
- audit trail append-only para eventos críticos;
- dados e ficheiros privados fora da exposição pública;
- SHA-256 de anexos/evidências quando aplicável;
- cifragem de segredos;
- retenção/minimização;
- consentimento e finalidade;
- observabilidade sem guardar conteúdo sensível;
- rate limiting nos endpoints públicos;
- protecção contra enumeração;
- idempotência em integrações;
- PT-AO em toda a interface.

Considerar o contexto legal/regulatório de Angola e a natureza de seguradora/instituição financeira não bancária, sem inventar requisitos legais específicos quando não estiverem confirmados.

## 18. PWA e experiência móvel
O SUPER Comercial deve ser PWA instalável, responsivo e optimizado para telefone:
- inputs sem zoom automático no iOS;
- header móvel contextual;
- offline apenas para shell seguro, nunca para dados comerciais sensíveis não autorizados;
- Web Push opt-in;
- actualizações de Service Worker assistidas;
- splash institucional SUPER;
- drag & drop nos anexos;
- tabelas adaptadas ao mobile;
- sem overflows horizontais indevidos.

## 19. Centro de Actualizações
Quero o mesmo padrão institucional:
- migrações versionadas e idempotentes;
- ledger SHA-256 de migrações históricas;
- integridade imutável;
- pré-validação de esquema;
- backup/preflight quando aplicável;
- worker/execução resiliente;
- diagnóstico;
- RELEASE-VALIDATION;
- pacote incremental + base completa em cada release;
- prova `base anterior + incremental = nova base`.

## 20. Primeira entrega
Comece pela **v1.0.0 — Fundação do SUPER Comercial e CRM Institucional**.

Quero que a primeira entrega inclua pelo menos:
1. estrutura base da aplicação;
2. identidade visual SUPER;
3. login técnico local de emergência apenas para Super Administrador;
4. cliente SSO SUPER GCH preparado/configurável;
5. RBAC comercial;
6. leads;
7. contactos/empresas;
8. oportunidades/pipeline;
9. actividades/tarefas;
10. SLA inicial;
11. cockpit do Director Comercial;
12. Pesquisa Global;
13. auditoria;
14. PWA;
15. diagnóstico/health;
16. Centro de Actualizações;
17. conector preparado para receber indicações do SUPER Embaixador;
18. schema SQL completo;
19. documentação de instalação/configuração;
20. validadores automáticos;
21. pacote ZIP base completa v1.0.0 com SHA-256.

Não use dados ou segredos de produção fictícios. Forneça ficheiros `.example` para configurações sensíveis.

Antes de avançar para módulos adicionais, valide integralmente a v1.0.0 e explique a arquitectura, permissões, modelo de dados, fluxo SSO e integração GCH ↔ SUPER Comercial.