Orquestração do Runtime Argus

O que Orquestração do Runtime Argus faz?

Use quando uma tarefa se beneficiar de estado durável, artefatos, experimentos, execução em segundo plano, revisão independente, pausa/retomada ou continuação além de um único turno do modelo. Não use para uma resposta rápida, inspeção simples de leitura ou uma operação pequena que o host atual possa finalizar e verificar diretamente com segurança.

Limitações conhecidas

• Argus não fornece um push/callback universalmente portável de Needs you para todos os operadores externos. O operador externo deve inspecionar ativamente o status/saída compacta do Argus em limites significativos. A detecção de intervenção pode não ser em tempo real quando o host não pode manter monitoramento durável, e esta skill proíbe reivindicar supervisão não monitorada nesse caso.
• Os adaptadores Hermes Agent e Claude Code são atualmente validados por documentação, não testados por execução local neste host.
• Alguns comandos da skill do Copilot CLI na documentação atual estão ausentes da build 1.0.39 testada localmente, portanto, a detecção de funcionalidades é necessária.

Modelo operacional de duas partes e configuração

Existem exatamente duas partes operacionais:

1. Operador externo: OpenClaw, Hermes Agent, Claude Code, Codex CLI, Copilot CLI ou outro agente com capacidade de shell seguindo esta skill. Ele prepara a missão, lança e observa o Argus, gerencia perguntas do operador dentro da autoridade delegada, verifica artefatos e relata de forma compacta.
2. Argus: o sistema supervisionado durável que planeja, executa, revisa, persiste estado, levanta perguntas e produz evidências e artefatos.

Qualquer CLI interna de modelo/provedor que o Argus use — como codex, copilot, claude, pi, opencode ou grok — é configuração do Argus e um detalhe de implementação, não um terceiro papel, ator par ou parte separada neste procedimento. O operador externo pode selecionar ou verificar o modelo/provedor interno configurado do Argus durante o pré-voo quando operacionalmente necessário e autorizado; caso contrário, trata o Argus como um sistema supervisionado durável. Não infira a configuração do Argus a partir da identidade do operador externo, mesmo quando os nomes coincidirem.

Resolva o executável explicitamente; não assuma um caminho de instalação universal. Shell POSIX:

if [ -n "${ARGUS_BIN:-}" ]; then
  : # operador forneceu um caminho executável
elif command -v argus >/dev/null 2>&1; then
  ARGUS_BIN="$(command -v argus)"
elif [ -n "${ARGUS_INSTALL:-}" ]; then
  ARGUS_BIN="$ARGUS_INSTALL/.venv/bin/argus"
else
  echo "Defina ARGUS_BIN ou ARGUS_INSTALL" >&2; exit 2
fi

PowerShell nativo:

if ($env:ARGUS_BIN) {
  $ArgusBin = $env:ARGUS_BIN
} elseif (Get-Command argus -ErrorAction SilentlyContinue) {
  $ArgusBin = (Get-Command argus).Source
} elseif ($env:ARGUS_INSTALL) {
  $ArgusBin = Join-Path $env:ARGUS_INSTALL ".venv\Scripts\argus.exe"
} else {
  throw "Defina ARGUS_BIN ou ARGUS_INSTALL"
}

Os exemplos de comando abaixo usam a sintaxe POSIX "$ARGUS_BIN" .... No PowerShell, invoque o caminho resolvido como & $ArgusBin ....

Para um checkout de fonte, ARGUS_INSTALL="$HOME/src/Argus" é apenas um exemplo, não um padrão portável. Registre o caminho absoluto do executável resolvido. Nunca baixe, reinstale, altere a configuração interna de modelo/provedor do Argus ou amplie permissões silenciosamente.

Procedimento operacional principal

1. Escolha um workdir próprio e um limite de segurança real. Use um diretório absoluto dedicado por projeto Argus. Nunca sobreponha a hierarquia de diretórios de outro projeto Argus ativo. Não mova, exclua ou escreva compartilhadamente enquanto seu daemon estiver ativo. Trabalho paralelo verdadeiro obtém projetos separados. O workdir é um limite de propriedade, não uma sandbox. ARGUS_SKILL_SAFE_MODE=1 adiciona proteções, mas não é isolamento para todos os backends. Antes de preparar entradas sensíveis, exija sandboxing verificado para o backend selecionado ou execute o Argus em um limite de SO/contêiner apropriadamente isolado. O modo não monitorado padrão pode conceder acesso de agentes internos além do workdir.
2. Prepare entradas limitadas. Copie apenas entradas relevantes para a tarefa e seguras para divulgação em inputs/. Escreva OBJECTIVE.md com resultado, não objetivos, caminhos de saída, critérios de aceitação, limites de autoridade e requisitos de revisão/citação. Não prepare histórico de conversa ambiente, credenciais ou dados privados não relacionados.
3. Pré-voo a partir do workdir exato. Execute "$ARGUS_BIN" doctor, depois teste "$ARGUS_BIN" --status. Use doctor --deep apenas quando a autenticação do backend precisar ser verificada; não adicione essa latência de rede/auth a cada pré-voo de rotina. Deep Doctor não é prova universal de autenticação ativa: quando relatar um token não verificado, capacidade offline ou rota inacessível, use a sonda de prontidão ativa não mutante documentada desse backend antes do despacho. Continue apenas se as verificações necessárias passarem, o projeto/workdir pretendido for identificado, nenhum conflito de propriedade existir, e qualquer escolha de modelo/provedor interno operacionalmente necessária estiver instalada e autenticada. O operador externo pode selecionar ou verificar essa configuração do Argus aqui quando autorizado, mas não deve tratá-la como outra parte operacional. A ajuda de nível superior atual do Argus é intencionalmente concisa e pode omitir flags de automação suportadas; antes de usar --notify, daemon, bounded ou superfícies de API contra outra build, verifique-as a partir dos docs/parser dessa build ou de uma sonda segura. Veja references/argus-runtime-surfaces.md.
4. Mantenha a configuração de execução interna explícita apenas quando necessário. Prefira o modelo/provedor interno já configurado, instalado e autenticado do Argus. Qualifique nomes de provedores onde o Argus exigir. Não altere silenciosamente a configuração após uma verificação de prontidão falhada; diagnostique primeiro e obtenha aprovação quando a alteração exceder a autoridade delegada.
5. Despache uma missão independente. A partir do workdir, dê ao Argus um objetivo autocontido nomeando entradas e saídas preparadas. Solicite inspecionar → executar → validar → reparar → fechamento de artefato final. Delegue à política nativa de risco/Revisão Vertical do Argus; exija revisão independente explicitamente apenas quando o contrato da tarefa ou risco material assim o exigir. Mantenha uma entrega limitada por missão. Para uma missão limitada única onde o aprendizado reutilizável não é solicitado e a política de implantação permitir, defina ARGUS_SKILL_REQUIRE_POST_TASK_LEARNING=0 para evitar a chamada de modelo de aprendizado pós-tarefa padrão; caso contrário, preserve a política de aprendizado configurada. Use o cockpit interativo quando disponível; para execução destacada, use as superfícies de daemon/bounded documentadas do Argus, não um loop de shell improvisado.
6. Preserve limites de evidência dentro do Argus. Argus pode separar planejamento, engenharia e revisão internamente. Exija missões do tamanho de decisões e alterações de artefatos com evidência. Quando a política do Argus exigir revisão independente, ela deve inspecionar artefatos reais, limites, citações e conclusão. Estas são responsabilidades internas, não partes adicionais no modelo operacional externo. Prefira uma verificação decisiva por reivindicação; evite evidências cerimoniais duplicadas ou turnos extras de modelo.
7. Monitore usando a capacidade disponível mais forte do host. Siga o adaptador selecionado em references/adapters/. APIs de processo/background do host melhoram a observação, mas não são a fonte de verdade: o estado do projeto durável do Argus é. Use o daemon destacado do Argus apenas onde o ambiente ativo preserva processos do host. Caso contrário, salve a identidade exata do workdir/projeto e relance o Argus contra esse estado em um turno posterior. Se nenhum lançamento destacado for permitido, mantenha um cockpit em primeiro plano ou peça ao usuário para deixá-lo em execução; nunca reivindique monitoramento não monitorado.
8. Execute o loop de perguntas pendentes em cada limite. Inspecione "$ARGUS_BIN" --status no despacho, em cada verificação de status significativa, após resultados bloqueados/pausados/replanejados, antes de deixar uma execução não monitorada, após responder e antes do encerramento. waiting on you : N unanswered question(s) é um sinal de parada. Quando disponível, inspecione também o prompt Needs you do cockpit/Web UI. Na build validada do Argus 0.1.1, operadores com capacidade de API podem inspecionar GET /api/projects/{sid}/status ou GET /api/projects/{sid}/snapshot?compact=true; ambos expõem pending_questions, enquanto snapshots completos expõem linhas em backlog. Essas rotas de leitura podem permanecer não autenticadas mesmo quando ARGUS_SKILL_WEB_TOKEN estiver configurado: mantenha-as apenas em loopback, ou coloque-as atrás de uma VPN confiável/proxy reverso autenticador; nunca as exponha diretamente a uma rede não confiável. Detecte recursos dessas rotas em outras builds. Prosa de progresso sozinha é insuficiente.
9. Classifique cada pergunta. Um marcador durável não resolvido é uma linha de backlog com pending_question não vazio; um cartão tipado também tem operator_decision.status == "pending", mais id, question, reason, evidence e options opcionais. Isso não é uma pergunta de chat informacional, texto de objetivo, prosa de revisão ou /ask comum. Trate o marcador durável como bloqueador mesmo ao lado de texto failed, paused_operator ou com aparência de sucesso. Deixe o Argus reter roteamento técnico reversível a menos que uma pergunta levantada claramente caia dentro da autoridade delegada. Escale credenciais/segredos, gastos, exclusão/force-push/publicação/envios externos, ações irreversíveis ou voltadas para fora, mudanças de segurança/limite de confiança, decisões legais/licença, mudanças materiais de escopo/aceitação e escolhas ambíguas de alto impacto.
10. Responda através de uma superfície autoritativa. Prefira o cartão Needs you específico do item no cockpit terminal/Web. Na build validada do Argus 0.1.1, clientes de API podem usar POST /api/projects/{sid}/decisions/{decision_id}/resolve com {"option_id":"…","note":"…"}, ou legado POST /api/projects/{sid}/backlog/{item_id}/answer com {"text":"…"}. Uma resposta normal do cockpit ou POST /api/projects/{sid}/message é roteada pelo Manager apenas quando exatamente uma pergunta está pendente; quando existirem várias, direcione o cartão/item específico. "$ARGUS_BIN" --notify '<answer>' enfileira orientação e pode ser vinculado pelo Manager apenas quando exatamente uma pergunta está pendente; confirmação de fila não é resolução. Detecte recursos de rotas não cockpit em outras builds. Nunca adivinhe em nome do usuário.
11. Verifique o registro e depois retome. Na build validada, exija resolved: true onde a superfície o retornar. Confirme que o antigo pending_question foi limpo e que uma resolução foi registrada. Quando um cartão de decisão tipado existir, exija também que esse cartão se torne resolved; perguntas legadas não tipadas podem não ter cartão ou resolution_id. Observe a continuação em seu estado real pendente, em execução, concluído ou parado, em vez de exigir que ainda esteja ativo no momento da inspeção. Uma decisão stop em vez disso aborta o item, preserva o trabalho, desativa o modo contínuo e não cria continuação. Reexecute o status e verifique se a execução retomou, concluiu ou parou conforme pretendido. Se o marcador permanecer, esclareça ou escale; não envie palpites duplicados.
12. Inspecione sem importar a trajetória. Use status/cockpit para missão atual, papel, estágio, backlog, resultado, posição verificada mais recente e Needs you. Trate backlog mais a evidência verificada mais recente como a fronteira. Mantenha transcrições brutas, logs de daemon, I/O de agente, logs de uso e livros-razão privados locais.
13. Recupere e verifique artefatos. Leia caminhos de saída nomeados. Verifique existência, escopo solicitado e testes decisivos. Resolva toda citação material à fonte preparada; rejeite citações fabricadas, desatualizadas ou incompatíveis com a reivindicação. Nunca infira sucesso a partir de uma mensagem de progresso.
14. Recupere a partir de estado durável. Retome trabalho de escrita/execução pausado pedindo ao Argus que retome a partir de estado durável com um objetivo de retomada autocontido, não uma resposta de chat inline. Se um thread de execução interna não puder retomar, use checkpoints/cápsulas do Argus. Diagnostique perguntas não resolvidas, propriedade, prontidão de modelo/provedor interno, orçamento/cooldown e infraestrutura antes de alterar a configuração ou objetivo do Argus.
15. Encerre apenas com evidência. Finalize quando o objetivo limitado for atendido, artefatos e verificações decisivas passarem, o veredito do Revisor exigido for done, e nenhuma pergunta/cartão pendente permanecer. continue, replan_requested, blocked, pausa de pesquisa ou Needs you não respondido não é conclusão. Distinga conclusão de missão de conclusão de projeto/estágio. Use references/closeout-checklist.md.

Fallbacks de capacidade

• Nenhuma descoberta nativa de skill: forneça o pacote completo ou instrua explicitamente o host a ler este arquivo e o adaptador correspondente; não reivindique ativação automática.
• Sem shell: o host não pode operar diretamente o Argus local. Use uma integração remota aprovada de shell/terminal ou transfira passos exatos do operador; marque a execução como bloqueada em vez de simulá-la.
• Shell mas sem API de processo: prefira --daemon do Argus apenas quando o ambiente preservar processos; sempre persista a identidade do projeto/workdir e reentre com status/cockpit. Não coloque em segundo plano com &, nohup frágeis ou loops de sleep/poll a menos que o ambiente documentado do host torne esse o único caminho aprovado.
• API de processo mas não durável entre sessões do host: use-a apenas para logs ao vivo; o estado do projeto durável do Argus permanece a âncora de recuperação, e o daemon pode precisar ser relançado.
• Sem cliente HTTP/API: use cockpit terminal/Web e --status. Nunca exija acesso à API para o loop de perguntas.
• Nenhuma rota de aprovação interativa: falhe fechado em ações com portão de aprovação. Separe pré-voo seguro de lançamento mutante, ou peça ao humano para aprovar através da UI suportada desse host. Nunca ignore flags de aprovação/sandbox apenas para executar não monitorado.
• Nenhuma execução não monitorada permitida: mantenha uma sessão interativa aberta ou pare com uma instrução precisa de retomada e estado não resolvido. Relate o monitoramento como condicional, não ativo.

Privacidade, autoridade e retorno

Prepare dados mínimos. Mantenha Web UI apenas em loopback a menos que o usuário aprove acesso remoto protegido. Instruções atuais do usuário e evidências recentes substituem planos anteriores ou sugestões de runtime.

Retorne apenas à superfície de invocação: identidade do workdir/projeto, resultado/fronteira compacto, veredito do Revisor, caminhos de artefato, validação decisiva, exceções de citação,

…

[truncado para tradução]