O problema
Backlogs crescem mais rápido do que times executam. Ciclos longos. Hand-offs frágeis. Contexto perdido entre silos. Custo opaco.
LLMs prometeram velocidade — entregaram demos. O que falta não é mais um modelo. É orquestração.
A tese
Dédalo é um pipeline determinístico que coordena agentes especializados ao longo de 11 fases — da entrada de um item de backlog até o deploy auditado.
Modelos locais para o trabalho estruturado. Modelos premium para o trabalho criativo. Humanos nos gates que importam. Multi-projeto desde o dia zero.
Como funciona
Cada transição persiste um phase_event — fonte de verdade para auditoria, dashboards e postmortem.
flowchart LR IN([Ingress]) --> CL[Classificar] CL --> PR[Priorizar] PR --> DI[Discovery
5 estratégias] DI -.gate.-> RF[Refinar Plan] RF -.gate.-> EX[Executar] EX --> VA[Validar QA] VA -.gate.-> PU[Publicar
merge + deploy] PU --> AR([Arquivar]) classDef gate fill:#C8A24A,stroke:#7A2A2A,color:#0E1116,stroke-width:2px class DI,RF,VA gate
| Fase | O que faz | |
|---|---|---|
| 1 | Input | Idempotência por content_hash em janela de 24h. Transactional outbox dispara o workflow Temporal. |
| 2 | Classificação | Tipo, tags e alvo de backlog em paralelo com pesquisa de contexto via memória semântica. |
| 3 | Backlog Features | Curadoria coletiva agendada — fila comum vira fila ordenada. |
| 4 | Priorização | Score 0–100 por item baseado em tipo, tags e metas do projeto. |
| 5 | Discovery | Cinco estratégias paralelas — mercado, histórico, docs, técnica, estado — sintetizadas em um sumário executivo. |
| 6 | Refinamento | Plan estruturado com tarefas, ACs e estimativa, sob crítica adversarial automática. |
| 7 | Backlog Tarefas | Decomposição agendada de itens prontos em sub-tarefas executáveis. |
| 8 | Execução | Worktree isolada. Code executor escolhido por tamanho da tarefa: Claude Code CLI (L/XL) ou OpenHands SDK (S/M). |
| 9 | Validação | QA determinística + AC checker LLM + auto-rebase preventivo. Loop até três tentativas com triagem de falhas. |
| 10 | Publicação | Rebase, merge, build, deploy, smoke test. Conflito tardio reabre Validação, não resolve em silêncio. |
| 11 | Arquivamento | Postmortem estruturado, memória semântica e release notes. O que falhou vira sinal para o próximo item. |
Profundidade técnica
Cada fase tem um especialista. Cada especialista tem ferramentas próprias, prompts versionados, custo rastreado e fallback automático.
O orquestrador (Temporal) garante durabilidade. Os agentes garantem competência. E o sistema gera sua própria documentação — diariamente, sem intervenção.
Autonomia além do pipeline
Três workflows de background rodam continuamente, sem intervenção humana. Cada item executado torna o próximo mais inteligente — memória acumula, documentação se auto-regenera, padrões emergem.
Diário · cron 06:00 UTC
6 agentes LLM em pipeline sequencial — descoberta, extração por chunk, análise de git, agrupamento, consolidação e avaliação de gaps — geram e atualizam a documentação técnica do projeto. Incremental: só re-processa arquivos modificados. Custo local: ~$0 (LMStudio). Fallback para Claude Haiku apenas em falha de infra.
A cada 24h · ou sob demanda
Mantém a base vetorial do projeto atualizada (pgvector 768-dim, nomic-embed-text-v1.5). Faz glob de docs, lê metadados git sem trafegar conteúdo pelo payload Temporal, rechunka e re-embeda apenas o que mudou. Auditoria amostral via doc_auditor detecta docs obsoletos.
Cron · ou on-demand
Sintetiza os padrões acumulados em memória em uma árvore de conhecimento estruturada por projeto. Alimenta o context_researcher e o discovery_history com contexto de maior granularidade — itens futuros chegam com mais contexto do que os anteriores.
Diferencial
Quatro gates separam o que é decidível por máquina do que precisa de assinatura humana — três sempre presentes, mais gate de aprovação de produção para deploys em dois estágios. Nada vai pra produção sem mãos no botão.
| Gate | Quando | SLA | Vereditos |
|---|---|---|---|
| discovery_review | Após Discovery, antes do Refinamento | 1 hora | approved · rejected · rework (até 2×) · expired |
| execution_gate | Após Plan aprovado, antes da Execução | 1 hora | approved · rejected · rework · expired |
| publication_gate | Após Validação, antes do merge e deploy | 2 horas | approved · rejected · rework · expired |
| production_approval | Após staging deploy, antes do deploy de produção (projetos com estágio prod separado) | 24 horas | approved · rejected |
| reconciliation_review | Conflito tardio pós-deploy (escalação) | 24 horas | approved · rejected (até 3×) |
Princípio de design
Dédalo construiu o sistema com os limites; Ícaro caiu por ignorá-los.
— branding/nome-do-produto.md
Falha alto e ruidoso. Sem fallback silencioso.
Nada de mock que mascara erro. Nada de retry que esconde regressão. Nada de gate que se auto-aprova. Os limites do sistema são o sistema.
Em números
11
Fases na máquina de estados
30+
Agentes especializados — pipeline + background intelligence
4
Executor backends — worktree, Docker, SSH, sandbox
6
Modelos LLM default — locais e premium
4
Gates humanos — 3 obrigatórios + aprovação de produção
0
Dependência cloud no caminho crítico
Open source. Self-hosted. Multi-tenant desde o dia zero.
Iniciar conversa