Três papéis, um runner programático: planejar antes, implementar feature a feature, validar em milestones.
Missions divide o trabalho de agentes em três camadas que não compartilham um único chat inchado.
Orquestrador — o gerente de projeto. Sessão longa com interactionMode: mission. Escreve o contrato de validação antes de fixar features, mantém artefatos compartilhados, chama propose_mission para aprovação e depois start_mission_run. Não acumula detalhe de implementação.
Worker — o implementador. O mission runner dispara uma sessão fresca por feature de features.json. Cada worker recebe spec + skill, implementa com TDD local e devolve handoff JSON. Workers não declaram "pronto" — validators decidem.
Validator — o inspetor. Ao completar features de um milestone, o sistema auto-injeta features scrutiny-validator e user-testing-validator. Sub-droids revisam código e testam fluxos reais contra IDs do contrato. Falhas viram fix features; o loop repete.
Pense como… uma produção cinematográfica. O diretor (orquestrador) tem roteiro e cronograma mas não opera cada câmera. Cada cena tem equipe dedicada (worker) com call sheet limpo. No fim de cada ato, QC (validators) roda dailies e lista de refilmagens. O diretor não escolhe manualmente "take 47" — um runner programático avança a fila.
mission-orchestrator, mission-worker, tag mission-session. Sessões filhas indexadas via decompMissionId em session-discovery-index.json.
Loop programático pós-start_mission_run: "pega a lista de features e dispara um worker por feature em ordem." Retomar após pausa continua na feature pendente. Heurística de custo: total runs ≈ #features + 2 × #milestones (+ rounds de fix).
Prompt no binário: NEVER create features with skillName scrutiny-validator or user-testing-validator — o sistema auto-injeta no fim do milestone.
Orquestrador pode chamar Task com subagent_type: "worker" para exploração — distinto do runner formal executando features.json.
USER → /missions or droid exec --mission
→ ORCHESTRATOR (interactionMode=mission)
→ mission-planning + define-mission-skills
→ ~/.factory/missions/<uuid>/
→ propose_mission → (approve) → start_mission_run
→ MISSION RUNNER (programmatic, sequential)
→ FEATURE WORKER (fresh session each)
→ handoffs/*.json
→ milestone? → scrutiny-validator + user-testing-validator
→ pass? → next milestone : fix features → re-validate
→ MISSION CONTROL (Ctrl+T, orchestrator only)
As duas tools mission-specific do orquestrador e os eventos de progresso que o runner emite.
# Orchestrator tools propose_mission # present proposal to operator start_mission_run # kick programmatic runner # Progress events (progress_log.jsonl) mission_run_started worker_started worker_selected_feature worker_completed worker_failed milestone_validation_triggered # Validator skillNames (auto-injected — do NOT add manually) scrutiny-validator user-testing-validator~/.factory/droids/ (custom sub-droids)
worker.md # generic feature worker scrutiny-feature-reviewer.md # per-feature code audit user-testing-flow-validator.md # assertion IDs from contract
planning → awaiting_input → initializing → running ↔ paused / orchestrator_turn → completed | cancelled
Clique em cada papel. Veja o que ele controla — e o que deliberadamente não faz.