Skip to main content

Sessão: Evolução Semanal OktoLabs

Data: 16 de janeiro de 2026 Participantes: Claude + Fabiano Status: Em andamento Tipo: Acompanhamento e análise de progresso

Contexto​

Esta sessão analisa a evolução do projeto desde a sessão de produtização (11/01/2026), incorporando:

  • Changelog das alterações em todos os repositórios
  • Conversas da semana entre os sócios
  • Status atual do MVP

1. Progresso Técnico (Do Changelog)​

Implementações Concluídas​

FeatureStatusComponentes Afetados
SubworkflowsCompletoIDE, Engine, Persistence, WebSockets, CLI
Runner SystemCompletoIDE (RunnerSelector), CLI (--connect)
RBACCompletoIDE, PDP, User Service
PrometheusCompletoEngine, Metrics API
Multi-tenancyCompletoRealms, Teams, Projects
Dark ModeCompletoReact IDE
Clerk Auth CLICompletoCLI

Detalhes por Repositório​

omni_flow_react_ide (+21,452 linhas)​

  • RunnerSelector component
  • SecretForm, SecretList, SecretValueViewer
  • AccessSimulationTab, GroupsTab, MembershipsTab, TeamsProjectsTab
  • ConnectionValidator, WorkflowManager melhorado
  • Dark mode completo

omni_flow_engine (+18,052 linhas)​

  • Prometheus integration nativo
  • FileDiffTool (+448 linhas)
  • Conditional entity
  • Security module
  • Token estimation aprimorado

omni_flow_cli (+11,339 linhas)​

  • BFF client (+1,021 linhas)
  • Clerk auth (+458 linhas)
  • Runner package completo
  • Workflow selection screens

Impacto no MVP​

  • Features "já prontas" aumentaram de 11 para ~18
  • Observabilidade (Prometheus) antecipada
  • Multi-tenancy implementado antes do previsto
  • Docker Compose 100% funcional

2. Discussões Arquiteturais (Das Conversas)​

2.1 Nova Arquitetura: WebSocket → HTTP + Fila​

Proposta discutida:

┌─────────┐     HTTP Request      ┌────────────────┐
│   IDE   │ ──────────────────────▶ Engine Runner  │
└─────────┘                        │ (execution_id) │
                                   └───────┬────────┘
                                           │
                                           ▼
                                  ┌────────────────┐
                                  │     Fila       │
                                  │ Intermediária  │
                                  └───────┬────────┘
                                           │
┌─────────┐      WebSocket                 │
│   IDE   │ ◀──────────────────────────────┘
└─────────┘   Eventos Realtime

Benefícios identificados:

  • Conexões stateless mais estáveis
  • Recuperação em caso de desconexão (reconectar com mesmo execution_id)
  • Escalabilidade de runners
  • Mitigação de instabilidade em redes externas (fora do Brasil)

Status: Em discussão - ainda precisa de análise antes de implementar

2.2 Resolução de Secrets​

Problema identificado:

  • Execução full no CLI exige resolução de secrets no backend
  • Isso envia dados sensíveis para o cliente (risco de segurança)

Cenários analisados:

  1. Backend calling CLI tools: Secrets resolvidos no backend (seguro)
  2. CLI full local: CLI acessa backend para resolver secrets (menos seguro)

Solução paliativa proposta:

  • Secret só usado no adapter (executado no backend)
  • Engine verifica permissão mas não resolve secret
  • Mantém separação de responsabilidades

Discussão pendente:

  • Usuário pode vazar secret via code entity/code tool
  • Isso é válido e acontece em qualquer ferramenta de mercado
  • Decisão: Pacificado - comportamento aceitável

2.3 Provider Padrão LiteLLM​

Proposta: Tirar seleção de provider da interface, usar LiteLLM como padrão

Benefícios:

  • Simplifica UX
  • Proxy universal
  • Reduz configuração inicial

Status: Em avaliação - faz sentido técnico

3. Infraestrutura​

Docker Compose Funcional​

  • make setup clona tudo nas pastas corretas
  • Docker compose funcionando com todas as alterações
  • Modelos locais (Ollama) funcionando bem

Arquitetura Atual em Docker​

Docker Compose
├── IDE (React)           - Frontend visual
├── BFF (8080)            - API gateway
├── Engine WS             - Execução de workflows
├── Chat WS               - Modo chat
├── Persistence API       - Persistência
├── PDP                   - Policy Decision Point
├── User Service          - Gerenciamento de usuários
├── ORN Registry          - Registro de recursos
├── Metrics API           - Métricas
├── Tracing API           - Distributed tracing
└── Demais serviços

Nota sobre CLI​

O CLI precisa rodar fora do Docker

Arquitetura ideal: Apenas BFF e IDE expostos no localhost CLI se conecta externamente via okto --connect

4. Gaps Atualizados​

Resolvidos desde 11/01​

  • Observabilidade (Prometheus integrado)
  • Multi-tenancy (Realms/Teams/Projects)
  • RBAC (Policies e Roles)
  • Runner System (IDE + CLI)
  • Subworkflows
  • Dark Mode
  • Auth CLI

Ainda Pendentes (MVP)​

  • Landing Page
  • Onboarding Wizard
  • Templates Iniciais
  • Documentação Getting Started
  • Deploy público

5. Pontos de Atenção​

5.1 Granularidade de Permissões (Discussão)​

  • Proposta de permissão POR agente em workflow
  • Proposta de permissão por workflow para adicionar agentes

Avaliação:

  • Válido no papel, mas precisa simplificar
  • Risco: Granularidade excessiva pode não se sustentar na prática
  • Status: Discussão inicial - a avaliar no futuro, sem prioridade definida

5.2 Segurança de Secrets​

  • Modelo atual tem gaps de segurança conhecidos
  • Solução paliativa implementada (resolver no adapter)
  • Solução definitiva ainda não definida

5.3 Discovery de Providers​

  • Discussão sobre popular interface dinamicamente
  • Universal adapter como serviço vs embedded
  • Fazer discovery no nível do realm

6. Experimentos e Aprendizados​

Tentativa: Agente no Backend + Ferramenta no CLI​

O que foi feito:

  • Chamada com sucesso de agente no backend e ferramenta no CLI

Problemas encontrados:

  • Muito complexo
  • Pouco/nenhum domínio sobre distribuição de responsabilidade
  • Muito lento

Decisão:

  • Rollback
  • Claude Code não faz dessa forma
  • Seguir modelo atual (mais simples)

Insight:

Segurança deve ser revista, mas não vale a complexidade arquitetural extrema

7. Próximos Passos Atualizados​

Imediato (esta semana)​

  • Continuar análise da arquitetura HTTP + Fila
  • Definir solução definitiva para secrets

Curto Prazo (próximas 2 semanas)​

  • Landing Page
  • Onboarding Wizard
  • Templates Iniciais

Decisões Pendentes​

DecisãoResponsávelPrazo
Arquitetura HTTP + FilaTime técnicoEsta semana
Provider discovery no realmA definirA definir
Universal adapter como serviçoA definirA definir

8. Comparativo: Plano vs Execução​

MVP Original (11/01)​

BlocoEstimadoComentário Atual
Landing Page5-7 diasAinda não iniciado
Onboarding Wizard4-5 diasAinda não iniciado
3 Templates5-6 diasAinda não iniciado
Documentação6-7 diasAinda não iniciado
Deploy7-9 diasDocker local funcional

Features Extra Entregues (não planejadas no MVP)​

  • Runner System (completo)
  • Subworkflows (completo)
  • RBAC avançado (completo)
  • Prometheus (completo)
  • Dark Mode (completo)

Observação: Time focou em robustez técnica antes do go-to-market. Isso é válido para garantir estabilidade, mas landing page e onboarding precisam avançar para validar com usuários externos.

9. Insights da Semana​

  1. Core técnico está muito maduro - 7 features novas implementadas
  2. Infra Docker funcional - Facilita onboarding de novos devs
  3. CLI com Runner é diferencial - okto --connect único no mercado
  4. Pendência: Go-to-market - Landing page e docs ainda não iniciados
  5. Arquitetura HTTP+Fila promissora - Mas precisa amadurecer antes de implementar
  6. Segurança é trade-off - Solução perfeita é muito complexa

10. Referências​

Changelog desta Sessão​

DataAlteração
2026-01-16Sessão criada com análise de progresso semanal