Factory Droid CLI Missions · Curso Visual

O que é Missions (e o que não é)

Ao final você saberá que Missions é um modo de interação — não um subcomando CLI — e quais pontos de entrada realmente o acionam.

Leia a versão simples ou abra a camada técnica em qualquer seção.

A ideia central

Missions é o modo de longo prazo do Factory Droid para construir software multi-feature. Você descreve o projeto, o sistema planeja, workers implementam feature a feature e validators checam cada milestone antes de avançar. Missões medianas duram ~2 horas; algumas levam dias.

A surpresa do reverse engineering em droid 0.150.1: não existe subcomando droid mission. Missions é um modo de interação — flag interactionMode: "mission" — acionado por slash commands no TUI ou por droid exec --mission headless.

Ao entrar em Missions, o CLI cria uma sessão orquestradora fresca com tag mission-session. Ela planeja, grava artefatos em ~/.factory/missions/<uuid>/ e eventualmente chama start_mission_run para o runner programático. O estado vive em disco, não na thread do chat.

Pense como… trocar um canteiro de obras de "consulta informal" para "modo projeto formal". Não é outro app — é o mesmo Droid CLI com comportamento diferente. O escritório (orquestrador) guarda as plantas; equipes (workers) chegam limpas por tarefa; inspetores (validators) assinam cada andar. Diferente de um chat único, as plantas persistem mesmo fechando o terminal.

Por baixo do capô

Subcomandos top-level em v0.150.1: exec, daemon, search, update, mcp, plugin, computer — sem mission.

Entrada TUI: /missions, /mission, /enter-mission. Strings no binário: Entered Mission mode., Already in Mission mode., Mission mode starts a fresh orchestrator session (conflita com --fork --mission).

Entrada headless exige --auto high ou --skip-permissions-unsafe, mais prompt ou -f mission.md. Saída inclui Mission started: com missionId.

System	Primitive	Work unit	Shared state
Droid Missions	`interactionMode: mission`	Feature + milestone	`~/.factory/missions/<uuid>/`
Kimi AgentSwarm	Tool `AgentSwarm` + `/swarm`	Item in `items[]`	`agents/<id>/wire.jsonl`
Claude Dynamic Workflows	Tool `Workflow` + script VM	`agent()` in JS	`workflows/scripts/*.js`

Em uma figura

Esquerda → direita: entradas válidas definem interactionMode=mission e criam sessão orquestradora; estado materializa em disco. A caixa tracejada é o que não existe.

No código

Duas entradas reais — slash no TUI e exec headless. Um comando que as pessoas esperam mas não existe.

droid exec --help (v0.150.1)

# Headless mission entry
droid exec --mission \
  --auto high \
  --worker-model <id> \
  --worker-reasoning-effort <level> \
  --validator-model <id> \
  --validator-reasoning-effort <level> \
  -f mission.md

# These do NOT exist:
droid mission    # ✗ no subcommand
droid missions   # ✗ no subcommand

~/.factory/sessions/…/2382c4e6-….settings.json (local RE evidence)

{
  "interactionMode": "mission",
  "tags": [{
    "name": "mission-session",
    "metadata": {
      "role": "orchestrator",
      "missionId": "2382c4e6-f93d-4cb1-b94c-c1bfaf86c2c0"
    }
  }]
}

Checagens reproduzíveis

droid --version
droid exec --help | rg mission
droid --help   # confirm no mission subcommand
jq '.interactionMode, .tags' \
  ~/.factory/sessions/*/2382c4e6-*.settings.json
strings -a ~/.local/bin/droid | rg 'propose_mission|start_mission_run'

Experimente: escolha um ponto de entrada

Clique em cada botão. Veja o que o CLI faria — e quais caminhos são becos sem saída.

Perguntas são bem-vindas — traga seu droid --help se a versão for diferente. Próximo: como Orquestrador, Worker e Validator dividem o trabalho depois de entrar em mission mode.