> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orquena.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Estratégia open source

> Como a Nuvexa avalia, integra e governa projetos open source e open-core.

# Estratégia open source

A Nuvexa utilizará projetos open source como bibliotecas, serviços externos, referências arquiteturais e conectores. Isso não significa juntar vários bancos e interfaces em um único processo.

> O kernel permanece próprio; os domínios mantêm fontes da verdade claras; aplicações externas entram por contratos e conectores.

## Modos de uso

### Referência

Estudamos entidades, fluxos, UX, APIs e decisões arquiteturais sem copiar código ou ativos.

### Integração headless

A Nuvexa oferece a interface e chama uma API externa por meio de um connector.

### Aplicação delegada

Um sistema externo opera uma superfície específica, como uma inbox, enquanto a Nuvexa troca eventos e identificadores controlados.

### Importação ou espelhamento

Um sistema é a fonte oficial e o outro recebe uma cópia orientada a leitura ou migração.

### Fork mantido

Exceção que exige licença compatível, equipe responsável, política de atualização, source notices e ADR específico.

## Regras de isolamento

* Aplicações externas utilizam banco próprio.
* Não recebem acesso global ao PostgreSQL da Nuvexa.
* Identificadores são ligados por `ExternalEntityMapping`.
* A fonte da verdade é declarada por entidade.
* Sincronizações bidirecionais exigem conflito, versão e prevenção de loop.
* Credenciais são criptografadas por organização.
* Provider e connector não definem autorização de domínio.

## Avaliação obrigatória

Todo candidato é analisado em quatro dimensões.

### Produto

* Funcionalidades relevantes.
* Multi-tenancy.
* APIs e webhooks.
* Exportação e portabilidade.
* Experiência do usuário.

### Engenharia

* Stack e dependências.
* Atividade de releases.
* Migrações e compatibilidade.
* Escalabilidade e observabilidade.
* Consumo operacional.

### Segurança

* Autenticação e autorização.
* Assinatura de webhooks.
* CVEs e processo de correção.
* Gestão de secrets.
* Isolamento de código e dados.

### Licença

* Licença por diretório ou arquivo.
* Diferença entre community e enterprise.
* Obrigações de rede da AGPL.
* Redistribuição e white-label.
* Notices, trademarks e source availability.

<Warning>
  Alterar logo, cores e telas não elimina obrigações de licença. Um repositório público também pode conter código enterprise ou termos source-available.
</Warning>

## Decisões atuais

| Área                 | Decisão                                                                 |
| -------------------- | ----------------------------------------------------------------------- |
| CRM                  | CRM nativo enxuto; Twenty como referência e connector; EspoCRM opcional |
| Inbox                | Inbox nativa; Chatwoot como referência e connector opcional             |
| Agendamento          | Scheduling nativo; Cal.com como referência                              |
| WhatsApp não oficial | WAHA para desenvolvimento e pilotos controlados                         |
| Automação visual     | Activepieces como candidato externo opcional                            |
| IA                   | Mastra como framework atrás dos contratos Nuvexa                        |
| Filas                | BullMQ sobre Valkey                                                     |
| Storage              | S3 genérico; SeaweedFS em avaliação; MinIO apenas compatibilidade       |

## Governança

As decisões técnicas ficam registradas em:

* `docs/research/open-source-stack.md`
* `docs/legal/open-source-policy.md`
* `docs/adrs/`
* READMEs de cada plugin ou connector

Uma implementação só poderá começar quando o uso estiver classificado e aprovado.

## Princípio final

A Nuvexa aproveita ecossistemas existentes sem terceirizar o próprio domínio, isolamento de tenant ou capacidade de evolução.