Roadmap técnico
O roadmap da Orquena é organizado por dependências, riscos e critérios de saída, não por datas arbitrárias. O primeiro produto completo será:Uma central de atendimento conectada ao WhatsApp, com agenda integrada e inteligência artificial que pode permanecer desligada, atuar como assistente ou operar como secretária automática.
Fase 0 — Arquitetura, especificação e identidade
- Visão, atores e jornadas.
- Requisitos funcionais e não funcionais.
- Threat model.
- Modelo inicial de dados.
- Contratos de tenant, events, jobs, providers e tools.
- ADRs iniciais.
- Nome, domínio e documentação Orquena.
- PRD do vertical de agendamentos.
- PRD de onboarding, Inbox e modos da IA.
- Modelo de controle humano e IA por conversa.
Critério de saída
Uma pessoa ou agente de implementação consegue entender produto, source of truth, estados, permissões, handoff e critérios de ativação sem inventar comportamento.Fase 1 — Foundation Repository
- pnpm e Nx.
- Namespace workspace
@orquena/*. - Next.js, NestJS e processos auxiliares vazios.
- TypeScript strict, lint, format e testes.
- Regras automáticas de dependência.
- CI, security scanning e documentation checks.
- Docker de desenvolvimento.
- Configuração tipada por ambiente.
Critério de saída
O monorepo instala, testa, valida boundaries e produz builds reproduzíveis.Fase 2 — Platform Kernel, autenticação e tenancy
- Better Auth.
- Login com Google usando identidade básica.
- Email e senha.
- Users e provider accounts.
- Customer accounts e organizations.
- Memberships e RBAC.
- Trusted tenant context.
- Audit log.
- Configuration e encrypted credentials.
- PostgreSQL, migrations e Row-Level Security.
- Transactional outbox.
- BullMQ sobre Valkey.
- Registry mínimo para capacidades first-party.
Critério de saída
Um usuário entra com Google ou email, cria a primeira organização e não consegue acessar dados de outro tenant por request, job, event ou cache.Fase 3 — Onboarding e ativação guiada
- Welcome personalizado.
SETUP_REQUIRED,SETUP_IN_PROGRESSeREADY.- Progresso calculado no backend.
- Etapas persistidas e retomáveis.
- Dados do negócio.
- Serviços.
- Profissionais.
- Horários, intervalos e regras simples.
- Decisão explícita de Calendar.
- Decisão explícita do modo de IA.
- Checklist e dashboard de setup incompleto.
Critério de saída
O usuário consegue completar, interromper e retomar o setup. A organização só viraREADY quando os resultados mínimos foram validados no servidor.
Fase 4 — Scheduling operacional
- Contacts mínimos necessários ao agendamento.
- Service Catalog e preços vigentes.
- Professionals.
- Horário da organização.
- Jornada, intervalos, blocks, time off e overrides.
- Availability determinística.
- Appointment holds.
- Confirmação atômica.
- Reagendamento e cancelamento.
- Calendar UI nativo.
- Events e reminder requests.
Critério de saída
Concorrência, timezone, duração, intervalos, preços, idempotência e tenant isolation passam por testes de integração.Fase 5 — Orquena Inbox e realtime
- Inboxes e channel bindings.
- Contacts resolvidos por identificadores de canal.
- Conversations e messages.
- Texto inbound e outbound.
- Read cursors e não lidas.
- Assignment.
- Estado do canal.
- Controle humano por conversa.
- Realtime com estado persistido authoritative.
- Notificações operacionais.
Critério de saída
Uma conversa pode ser recebida, persistida, exibida e respondida por humano sem IA. Recarregar a página reconstrói o estado pelo banco.Fase 6 — WAHA provider e sincronização inicial
- WAHA Core isolado.
- Uma conexão principal por organização no piloto.
- QR Code e lifecycle persistente.
- Webhooks autenticados e deduplicados.
- Reconexão e ação necessária.
- Importação limitada de contatos, chats e mensagens recentes.
- Sincronização em segundo plano sem bloquear onboarding.
- Caminho live independente da importação histórica.
- Métricas, kill switch e contract tests.
Critério de saída
O usuário lê o QR uma vez, recebe mensagens novas na Orquena Inbox e mantém a sessão após reinício comum. Importação parcial não bloqueia o canal live.Fase 7 — Google Calendar
- Projeto e OAuth client do Google.
- Login Google separado da autorização de Calendar.
- Consentimento incremental.
- Seleção de calendário.
- Refresh token criptografado.
- Orquena → Google Calendar.
- Create, update e cancel de evento.
- Mapping, idempotência, retry e reautorização.
- Estado e falhas no dashboard.
Critério de saída
Um appointment confirmado gera exatamente um evento externo; retry não duplica; falha do Google não desfaz o appointment da Orquena.Fase 8 — AI Runtime e simulador
- Mastra adapter.
- Agent templates e instances.
- Tool registry.
- Model Router.
- Policy Engine.
- Memory limitada e tenant-aware.
- Tracing, custo e evaluations.
- Simulador isolado.
- Tools para serviços, profissionais, disponibilidade, holds e appointments.
- Confirmações e limites de escrita.
Critério de saída
O simulador usa dados reais do domínio, nunca envia mensagem externa e demonstra uma conversa de agendamento sem acesso direto ao banco.Fase 9 — Modos da IA e handoff
- Default
OFFpor Inbox. COPILOTcom sugestões no composer.AUTOPILOTcom replies e tools controladas.- Override por conversa.
- Alteração do default com revisão de overrides.
- Estados
AI_ACTIVE,HUMAN_REQUIRED,HUMAN_ACTIVEePAUSED. - Handoff com resumo e notificação.
- Acknowledgement enviado no máximo uma vez.
- Takeover e retorno manual.
- Retorno por inatividade.
- Kill switch por organização.
Critério de saída
Assistente nunca envia sozinho; automático não inventa dados; takeover humano impede resposta automática; handoff continua no mesmo chat.Fase 10 — Dashboard e preparação do piloto
- Cards por capacidades habilitadas.
- Setup e integrações.
- Agendamentos do dia e próximos atendimentos.
- Conversas não lidas e aguardando humano.
- Uso da IA, sugestões e handoffs.
- Status do WhatsApp e Google Calendar.
- Alertas operacionais.
- Fluxo end-to-end do onboarding até o atendimento.
- Runbooks e fallback humano.
Critério de saída
Um negócio piloto completa o setup, conecta o WhatsApp, cadastra a operação, agenda, responde pela Inbox e testa os três modos da IA.Fase 11 — Beta controlado
- Autorização escrita do cliente piloto.
- Disclosure de risco do provider não oficial.
- Métricas de sucesso.
- Backup e restore.
- Incident response.
- Limites de custo e carga.
- Avaliação de respostas e ferramentas.
- Rollback de IA e provider.
- Ajustes de UX baseados no uso real.
Depois do MVP
- Meta Cloud API oficial.
- Microsoft Calendar.
- Sincronização bidirecional de calendário.
- CRM nativo progressivo.
- Campaigns com consentimento e aprovação.
- Email transacional e providers adicionais.
- Activepieces opcional.
- Connectors para sistemas existentes.
- Múltiplos WAHA nodes.
- Novos verticais.
- Marketplace somente após isolamento e governance maduros.
Critério universal
Uma fase só avança quando:- Contratos estão documentados.
- Source of truth está claro.
- Testes cobrem tenant, concorrência 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.