​

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.