# Estratégia White-label

## 1. Decisão arquitectural

O produto será white-label desde a fundação: identidade, políticas e catálogos serão configuráveis. A Versão 1 continuará como uma instalação de organização única para reduzir complexidade, acelerar a entrega e proteger dados clínicos.

White-label e multi-organização são conceitos diferentes:

- white-label adapta marca e operação sem alterar código;
- multi-organização aloja várias organizações na mesma aplicação com isolamento rigoroso.

Na Versão 1 implementamos o primeiro e preparamos o segundo, sem o activar.

## 2. Objectivos

- reutilizar o produto noutros consultórios;
- evitar nomes, cores, preços e políticas fixos no código;
- preservar histórico quando configurações mudam;
- permitir activação controlada de módulos;
- manter segurança clínica e financeira como prioridade;
- tornar futura migração para SaaS possível, mas não obrigatória.

## 3. Âmbitos

```text
Plataforma
└── Organização
    ├── Unidades
    ├── Utilizadores e perfis
    ├── Pacientes
    ├── Profissionais
    ├── Serviços e preços
    ├── Agenda
    ├── Processo clínico
    ├── Facturação
    └── Configurações
```

Mesmo numa instalação única, as entidades de negócio relevantes devem possuir `organization_id`. Isso explicita propriedade e reduz o custo de uma migração futura.

## 4. Isolamento de dados

Princípios obrigatórios:

- toda consulta de dados pertencentes a uma organização aplica o âmbito da organização actual;
- `organization_id` vem da sessão/credencial, nunca de um campo livre enviado pelo navegador;
- chaves únicas que variam por organização incluem `organization_id`;
- relacionamentos cruzados entre organizações são recusados;
- filas e tarefas agendadas transportam contexto explícito da organização;
- caches, ficheiros e exportações usam namespace separado;
- auditoria regista a organização;
- testes tentam deliberadamente aceder a dados de outra organização.

## 5. Estratégia da Versão 1

- criar uma organização inicial Makombe;
- associar utilizadores e dados de negócio a essa organização;
- resolver a organização pelo contexto autenticado;
- ocultar gestão de múltiplas organizações da interface;
- evitar selector de organização e administração global de clientes;
- manter integrações e domínio preparados para configuração futura.

Não serão implementados na Versão 1:

- contratação e pagamentos de subscrição;
- auto-registo de organizações;
- planos comerciais;
- administração SaaS global completa;
- troca de organização na mesma sessão;
- base partilhada em produção com vários clientes reais.

## 6. Marca e apresentação

O tema deve usar variáveis semânticas, não cores gravadas directamente em cada página:

- `primary`, `secondary`, `accent`;
- `background`, `surface`, `text`, `muted`;
- `success`, `warning`, `danger`, `info`.

Logótipos e cores são aplicados à interface e documentos. Acessibilidade prevalece: uma combinação inválida deve ser rejeitada ou corrigida por uma cor segura.

## 7. Domínios e URLs

Futuras opções:

- subdomínio da plataforma, como `makombe.exemplo.co.mz`;
- domínio próprio, como `app.makombe.co.mz`;
- domínio separado para demonstração.

O domínio deve ser verificado antes da activação. A organização nunca é determinada apenas pelo cabeçalho enviado pelo cliente sem validação contra a lista de domínios autorizados.

## 8. Módulos e funcionalidades

Funcionalidades podem ser activadas por organização, mas uma flag não substitui autorização.

Exemplos futuros:

- portal do paciente;
- pagamentos online;
- teleconsulta;
- seguradoras;
- laboratório;
- farmácia;
- múltiplas unidades.

A desactivação de um módulo oculta novas operações, mas não elimina nem torna inacessível o histórico necessário para auditoria.

## 9. Personalização de documentos

Cada modelo possui:

- organização proprietária;
- tipo e versão;
- identidade institucional;
- campos permitidos;
- texto legal aprovado;
- estado de rascunho/publicado/arquivado;
- autor e datas.

Templates não podem executar código arbitrário. Campos disponíveis devem vir de uma lista segura.

## 10. Integrações

Credenciais de email, SMS, pagamentos e armazenamento devem:

- pertencer a uma organização ou à plataforma;
- ser encriptadas em repouso;
- ser ocultadas após gravação;
- ter acesso limitado;
- possuir rotação e teste controlado;
- nunca aparecer em logs ou auditoria.

## 11. Administração da plataforma

No futuro, o operador da plataforma poderá gerir organizações, domínios, módulos e estado da instalação. Esse perfil não recebe automaticamente acesso a processos clínicos. Suporte técnico que necessite de acesso deve usar processo temporário, consentido e auditado.

## 12. Caminho para multi-organização

Antes de alojar vários clientes reais na mesma aplicação:

1. concluir auditoria de todas as tabelas e consultas;
2. implementar testes automáticos de isolamento;
3. definir estratégia de base partilhada ou base por organização;
4. isolar ficheiros, backups, cache, filas e pesquisas;
5. implementar administração global sem acesso clínico implícito;
6. realizar revisão de segurança e teste de penetração;
7. definir exportação e saída completa de cada cliente;
8. validar requisitos legais e contratos de tratamento de dados.

## 13. Critérios de aceitação

- mudar marca, contactos e políticas não exige alteração no código;
- dados históricos preservam valores e modelos usados na emissão;
- nenhuma configuração pode ultrapassar permissões ou mínimos de segurança;
- não existem nomes, preços, domínios ou cores do Makombe fixos na lógica;
- toda entidade organizacional possui propriedade explícita;
- testes comprovam que IDs de outra organização não concedem acesso.