Factory Droid CLI Missions · Curso Visual

Manual do operador

Supervisione como gerente de projeto: Mission Control, padrões de intervenção e missionModelSettings.

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

A ideia central

A Factory posiciona você como gerente de projeto de agentes, não debugger linha a linha. Mission Control (pressione Ctrl+T na sessão orquestradora) mostra features ativas, workers, progress log, uso de tokens e saída de validação.

Só funciona em sessões orquestradoras. String no binário: "Mission Control is only available in orchestrator sessions. Run /missions and select + New Mission first."

Quando intervir:

· Missão travada → pause o orquestrador, peça re-assessment.
· Worker preso → marque feature completa e siga.
· Escopo mudou → atualize o plano via conversa; orquestrador propaga aos artefatos.
· Validação falhando → deixe o loop de fix features rodar; não adicione validators manualmente.

Configure modelos em ~/.factory/settings.json em missionModelSettings — modelos separados para worker e validação, reasoning effort, flags de skip opcionais.

Pense como… uma torre de controle. Você não pilota os aviões (workers) nem inspeciona cada rebite (validators). Observa o painel (Mission Control), libera holds (pause/unblock) e desvia quando o tempo muda (mudança de escopo). A pista (runner) segue a menos que você pare explicitamente.

Dados do Mission Control (MissionStore)

Feature ativa + lista completa, histórico de workers, eventos progress_log, tokens por sessão, resumos de validação, controles: pause, redirect, unblock.

Notificações do daemon

mission_state_changed, mission_features_changed, mission_progress_entry, mission_heartbeat, mission_worker_started, mission_worker_completed.

Enterprise

missionPolicy.restrictedAccess + allowedUserIds restringem quem pode rodar missões.

Anti-padrões

Não use droid exec --fork --mission. Não trate Task/worker ad hoc como substituto de start_mission_run. Não pule mission-planning / define-mission-skills.

Em uma figura

Operador ↔ Mission Control ↔ orquestrador ↔ runner. Config de modelos em settings, herdada por sessões worker e validator.

No código

Settings locais observados e chaves documentadas para roteamento de modelos da missão.

~/.factory/settings.json (local RE sample)

{
  "hasSeenMissionOnboarding": true,
  "missionModelSettings": {
    "workerModel": "custom:kimi-k2.7-code-highspeed-3",
    "workerReasoningEffort": "xhigh",
    "validationWorkerModel": "custom:gpt-5.5-xhigh-2",
    "validationWorkerReasoningEffort": "xhigh"
  }
}

Additional documented keys

"missionOrchestratorModel"
"missionOrchestratorReasoningEffort"
"missionModelSettings.skipScrutiny"
"missionModelSettings.skipUserTesting"
"keepSystemAwakeDuringMissions"  # default true

droid exec --mission

--worker-model <id>
--worker-reasoning-effort <level>
--validator-model <id>
--validator-reasoning-effort <level>

Exemplo publicado pela Factory: orquestração em Opus-class, implementação em Sonnet/Opus, validação em GPT-5.3-Codex — papéis são model-agnostic.

Experimente: playbook + montador de config

Revise o checklist de intervenção e ajuste um bloco missionModelSettings de exemplo.

Mission Control mostra

Feature ativa + fila
Workers ativos / histórico
Timeline progress_log
Tokens por sessão
Saída de validação

Movimentos do operador

Pausar / retomar missão
Redirecionar escopo via chat com orquestrador
Marcar feature presa como completa
Aprovar propose_mission
Desbloquear awaiting_input

Você concluiu o curso. Reexecute os comandos de verificação da Lição 1 no seu droid, inspecione ~/.factory/missions/ e compare com o relatório RE em docs/droid-cli-missions-reverse-engineering.md.