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.
Cada item carrega um modo: mode = release agrega em batch via release_batches (singleton ativo por projeto), congela, passa por gate humano e deploya em conjunto; mode = hotfix corre individualmente e pode preemptar um release ativo. Items em modo release ficam em awaiting_release até o batch ser deployado pelo ReleaseManagerWorkflow.
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 + homolog] PU --> AW{mode} AW -- hotfix --> DP[Deploy Prod] AW -- release --> RB[(release_batch
singleton/projeto)] RB -.gate.-> DP DP --> AR([Arquivar]) classDef gate fill:#C8A24A,stroke:#7A2A2A,color:#0E1116,stroke-width:2px classDef batch fill:#2D5A4A,stroke:#0E1116,color:#F5F1E8,stroke-width:1px class DI,RF,VA,RB gate class RB batch
| 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. |
+ Release Management (Onda 13). Para items em modo release, um orquestrador longo (ReleaseManagerWorkflow) coordena rebase, gate humano, merge e deploy em batch. Conflitos passam pelo rebase_conflict_resolver (Claude Sonnet, cap USD 1.00/tentativa) antes de escalar para gate humano.
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 cada agente tem binding declarativo em agent_model_bindings — modelo default, fallback chain, política de custo e override por projeto, sem chumbar nada em código.
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.
Tempo real · outbox transacional
Neo4j como projeção 100% derivada de outbox_events — escrita na mesma transação dos phase_events/agent_runs/gate_decisions. Dois workflows Temporal: GraphSyncWorkflow (Cypher determinístico por mappers) e GraphitiExtractWorkflow (extração semântica via Bedrock). Consumo via HybridRecall (vector ⊕ grafo ⊕ recência) e tools MCP pipeline_rework_history, graph_topic_query.
Diferencial
12 tipos de gate cobrem cada handoff sensível — três sempre presentes (discovery_review, execution_gate, publication_gate), os demais conforme política do projeto. Nada vai pra produção sem mãos no botão.
| Gate | Quando | SLA | Vereditos |
|---|---|---|---|
| discovery_review | Após Discovery, antes do Refinamento | 12h | approved · rejected · rework · skip · auto-approve se synthesis_confidence ≥ 0.85 |
| execution_gate | Após Plan aprovado, antes da Execução | 8h | approved · rejected · rework · expired |
| publication_gate | Após Validação, antes do merge e deploy | 4h | approved · rejected · rework · expired |
| e2e_review | Após E2E exceder max_attempts |
24h | approved · rejected · rework |
| production_approval | Inline pré-Deploy Prod | 24h | approved · rejected |
| release_gate Onda 13 | release_batch congelado, antes do rebase/merge/deploy em conjunto |
24h | approved · rejected · mode_change (vira hotfix) · detach_from_release |
| release_conflict_review Onda 13 | Após rebase_conflict_resolver falhar ou exceder cap |
24h · cap 3× | approved · rejected · rework |
Toda decisão grava gate_decisions (auditoria com reviewer, comment, timestamp), tem SLA com escalação em 3 níveis (owner → tech_lead → manager) e aceita mode_change ou detach_from_release para realocar item entre trilhas sem reabrir o ciclo.
Operação
O agente memory_chat v2 opera o pipeline inteiramente via MCP server. Q&A sobre o projeto, listas de gates/releases/items, busca de memória. Escritas — submeter feature, aprovar/rejeitar gate, congelar release — não executam direto: viram ActionCards que o humano confirma com um clique.
Mesma superfície (MCP server :8765) que o Claude Code CLI humano usa — uma única fonte de verdade operacional para CLI e Dashboard.
Token por projeto em project_chat_tokens, cap monetário por turno via agent_policy.cost.caps_per_agent.memory_chat, auditoria por prefixo [chat por user@email] em todo comentário.
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
22+9
Agentes — 22 pipeline + 9 background intelligence (DocGen, MemorySync, KnowledgeTree, GraphMemory)
12
Tipos de gate humano — 3 obrigatórios, 9 por política de projeto
4
Executor backends — worktree, Docker, SSH, sandbox e2b
2
Trilhas de deploy — release (batch) × hotfix (individual), ambas com gate
pgvector
+ Neo4j
Memória híbrida — 768-dim vetorial ⊕ grafo bi-temporal via outbox transacional
Open source. Self-hosted. Multi-tenant desde o dia zero.
Iniciar conversa