Resumo
Poder operar o Cockpit pelo celular enquanto o notebook segue ligado e sendo o
motor de execução. O objetivo central não é só "ver de longe" — é aprovar e
decidir do celular: aprovar gates, responder elicitações e disparar comandos
sem precisar voltar ao notebook.
Problema / motivação
Hoje o Cockpit exige presença física no notebook para agir. Muitos momentos de
decisão são curtos e bloqueantes (um gate esperando aprovação, uma elicitação
pendente, um comando a disparar). Se o operador está longe da mesa, o trabalho
fica parado até ele voltar. A dor principal é essa: as decisões travam o
pipeline enquanto o operador não está no PC.
O que se pede (o "quê", não o "como")
Uma forma de, com o notebook ligado rodando o Cockpit:
- Ver o andamento de agentes/tarefas/gates a partir do celular.
- Ser notificado quando algo exige decisão (gate/elicitação).
- Agir do celular: aprovar/negar gates, responder elicitações, disparar
comandos — refletindo de volta na sessão que roda no notebook.
O operador está aberto a qualquer arquitetura que entregue isso; o time decide o
"como". Três caminhos plausíveis (não mutuamente exclusivos):
- A) Controle remoto — o celular espelha/controla a sessão do Cockpit que
roda no notebook (o notebook faz o trabalho pesado).
- B) Web/painel — o Cockpit expõe uma UI acessível pelo navegador do celular
(mesma rede ou via túnel), com o motor no notebook.
- C) App mobile — companion app que conversa com o daemon do notebook.
Prioridade das capacidades (do ponto de vista do operador)
- Aprovar/decidir do celular (gates + elicitações) — essencial.
- Notificação push quando há decisão pendente — alta.
- Visualização de andamento — desejável.
Considerações que o time deve avaliar
- Segurança/pareamento: ações remotas de aprovação precisam de autenticação
forte (o celular pode aprovar operações sensíveis). Túnel/rede local vs. exposição.
- Fonte da verdade: o motor permanece no notebook; o celular é cliente. Evitar
divergência de estado (a mesma decisão sendo tomada em dois lugares).
- Escopo de ações remotas: definir o que pode ser aprovado remotamente
(ex.: gates de push/merge/release talvez exijam confirmação extra).
Ambiente (referência do solicitante)
- OS: macOS 26.6.2 (arm64) · Cockpit: v0.11.1.0 · Antivírus: apenas nativo (Gatekeeper/XProtect)
- Observação: nenhuma issue aberta atual trata deste tema (verificado no repo em 2026-08-22).
Classificação [Confiança: ALTA]
enhancement — pedido de nova capacidade (operação mobile / decisão remota),
não um defeito. Origem: solicitação direta do operador.
Resumo
Poder operar o Cockpit pelo celular enquanto o notebook segue ligado e sendo o
motor de execução. O objetivo central não é só "ver de longe" — é aprovar e
decidir do celular: aprovar gates, responder elicitações e disparar comandos
sem precisar voltar ao notebook.
Problema / motivação
Hoje o Cockpit exige presença física no notebook para agir. Muitos momentos de
decisão são curtos e bloqueantes (um gate esperando aprovação, uma elicitação
pendente, um comando a disparar). Se o operador está longe da mesa, o trabalho
fica parado até ele voltar. A dor principal é essa: as decisões travam o
pipeline enquanto o operador não está no PC.
O que se pede (o "quê", não o "como")
Uma forma de, com o notebook ligado rodando o Cockpit:
comandos — refletindo de volta na sessão que roda no notebook.
O operador está aberto a qualquer arquitetura que entregue isso; o time decide o
"como". Três caminhos plausíveis (não mutuamente exclusivos):
roda no notebook (o notebook faz o trabalho pesado).
(mesma rede ou via túnel), com o motor no notebook.
Prioridade das capacidades (do ponto de vista do operador)
Considerações que o time deve avaliar
forte (o celular pode aprovar operações sensíveis). Túnel/rede local vs. exposição.
divergência de estado (a mesma decisão sendo tomada em dois lugares).
(ex.: gates de push/merge/release talvez exijam confirmação extra).
Ambiente (referência do solicitante)
Classificação [Confiança: ALTA]
enhancement — pedido de nova capacidade (operação mobile / decisão remota),
não um defeito. Origem: solicitação direta do operador.