> ## 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.

# Roadmap

> Sequência de especificação, provas de conceito e implementação da Orquena.

# Roadmap técnico

O roadmap da Orquena é organizado por dependências e critérios de saída, não por datas arbitrárias.

## Fase 0 — Arquitetura, especificação e marca

* Visão, atores e jornadas.
* Glossário oficial.
* Requisitos funcionais e não funcionais.
* Threat model.
* PRD do vertical de agendamentos.
* Modelo inicial de dados.
* Contratos de tenant, events, jobs, providers e tools.
* ADRs iniciais.
* Política de open source e inventário de terceiros.
* Nome Orquena aceito e documentado.
* Repositório GitHub renomeado para `Fulixts/Orquena`.
* Registro de domínio e triagem de marca antes do lançamento público.

### Critério de saída

Uma IA de implementação consegue entender o produto sem inventar source of truth, tecnologia, permission ou regra crítica. O nome atual não é confundido com o codinome histórico.

## Fase 1 — Foundation Repository

* Verificar Mintlify, Git remotes, webhooks e integrações após a renomeação do repositório.
* pnpm e Nx.
* Namespace workspace `@orquena/*`, sem publicação pública inicial.
* Next.js, NestJS e processos auxiliares vazios.
* TypeScript, lint, format e testes.
* Regras automáticas de dependência.
* CI, security scanning e documentation checks.
* Docker de desenvolvimento.

### Critério de saída

O monorepo executa apps vazios, valida boundaries e produz builds reproduzíveis sob a identidade Orquena.

## Fase 2 — Platform Kernel

* Authentication.
* Users, customer accounts, organization groups, organizations e memberships.
* Entitlements para organizações adicionais.
* RBAC e trusted tenant context.
* Audit log.
* Configuration e encrypted credentials.
* PostgreSQL, migrations e Row-Level Security.
* Transactional outbox.
* JobBus com BullMQ sobre Valkey.
* Plugin registry.

### Critério de saída

Testes comprovam que usuários, requests, jobs e events não atravessam organizações, inclusive quando os tenants pertencem à mesma conta comercial.

## Fase 3 — Plugin SDK

* Manifesto e lifecycle.
* Capabilities e permissions.
* Configuração por organização.
* Backend, UI, jobs, events e AI tools.
* Conformance kit.
* Compatibility e upgrade rules.
* Isolamento de plugins externos.

### Critério de saída

Um plugin de exemplo pode ser instalado, configurado, ativado, testado e removido sem acoplamento indevido.

## Fase 4 — Vertical de agendamentos

* Contacts.
* Service Catalog e versões de preço.
* Professionals.
* Horário de operação da organização.
* Escalas, intervalos, blocks, time off e overrides.
* Availability, holds e resources.
* Appointment, rescheduling e cancellation.
* Calendar UI.
* Reminder events.
* Feed iCalendar.

### Critério de saída

Concorrência, timezone, duração de serviço, intervalos, preços versionados, idempotência e tenant isolation passam por testes de integração.

## Fase 5 — AI Runtime

* Mastra adapter.
* Agent templates e instances.
* Tool registry.
* Model Router.
* Policy Engine.
* Memory policies.
* Tracing, cost e evaluations.
* Simulator.
* Human approval e kill switches.

### Critério de saída

O agente agenda somente através de tools, não inventa dados críticos e pode ser avaliado antes de ativação externa.

## Fase 6 — Inbox e realtime

* Inboxes e channel bindings.
* Conversations e messages.
* Attachments.
* Assignment e status.
* Internal notes e canned responses.
* AI/human handoff.
* Realtime e read cursors.

### Critério de saída

Mensagens são persistidas antes de consumers, duplicatas são neutralizadas e provider outage não remove histórico.

## Fase 7 — WAHA provider

* WAHA Core em topologia isolada.
* Uma conexão principal por organização no piloto inicial.
* `WEBJS` provider contract.
* QR Code e session lifecycle.
* Webhooks autenticados e deduplicados.
* Tenant resolvido pelo mapeamento armazenado da conexão.
* Text e media.
* Status e acknowledgements.
* Metrics, reconnect e kill switch.
* Contract tests com `NOWEB` e `GOWS`.

### Critério de saída

Reinício, duplicação, media, reconexão, isolamento entre tenants e node failure são testados antes do piloto.

## Fase 8 — CRM nativo inicial

* Leads e companies.
* Pipelines e stages.
* Opportunities.
* Tasks e activities.
* Custom fields controlados.
* Agent tools.
* Reports básicos.

### Critério de saída

CRM usa Contacts e Inbox sem duplicar identidade ou conversa.

## Fase 9 — Infraestrutura e storage

* Contrato S3-compatible.
* Managed storage adapter.
* SeaweedFS proof of concept.
* Backup, restore e migration.
* Observability stack.
* VPS Compose hardened.

### Critério de saída

Restauração completa e troca de storage provider são demonstradas.

## Fase 10 — Connectors experimentais

Executar provas de conceito separadas:

* Twenty API e metadata.
* EspoCRM API e OpenAPI.
* Chatwoot webhooks e delegated inbox.
* Cal.com bookings e schedules.
* Activepieces custom Orquena piece.

Nenhum connector entra no produto apenas porque a API respondeu. Cada um exige license gate, source-of-truth, security e reconciliation.

## Fase 11 — SaaS comercial

* Billing core e entitlements.
* Mercado Pago e Stripe providers.
* Usage metering.
* Plan limits.
* Onboarding self-service.
* Platform Admin.
* Support e incident runbooks.
* Privacy, retention e exports.

## Fase 12 — Expansão

* Meta Cloud API oficial.
* Google e Microsoft Calendar.
* Campaigns com consentimento e aprovação.
* Marketplace.
* Novos verticais.
* Múltiplos WAHA nodes.
* Infraestrutura distribuída quando testes e uso justificarem.

## Critério universal

Uma fase só avança quando:

* Contratos estão documentados.
* Regras e source of truth estão claras.
* Testes cobrem tenant e idempotência.
* Segurança e observabilidade foram adicionadas.
* Migrations e rollback existem.
* Documentação representa o comportamento real.
* Dependências open source passaram pelo gate de licença.