Controlo remoto e telemóvel
O Control Center é uma aplicação de computador, mas o trabalho que acompanha não
para quando se afasta da secretária. O controlo remoto emparelha o seu
telemóvel com o seu cc_server, através do
Remote, a aplicação complementar disponível
em remote.usectrl.dev, para poder acompanhar a frota a partir daí: ler mensagens
e tickets, responder a um agente, triar as suas notícias, sem que o áudio, a
transcrição, o código-fonte ou as credenciais que residem no servidor cheguem a
sair dele.
Pense nele como um companheiro do deck sobretudo de leitura. Não se destina a substituir o cliente de computador completo.
Transporte
Secção intitulada “Transporte”O telemóvel chega ao cc_server através de um WebSocket: uma ligação direta
(loopback, LAN, tailnet ou wss://) ou uma sala com acesso por convite num
broker de sinalização que retransmite tramas seladas. Não existe nenhum canal de
dados ponto a ponto.
O que o telemóvel pode fazer
Secção intitulada “O que o telemóvel pode fazer”O telemóvel emparelhado alcança uma fatia pequena e intencional da superfície do servidor:
- Ler tickets, agentes, espaços e as respetivas mensagens, e as suas notícias
- Responder: enviar uma mensagem num espaço, atualizar ou atribuir um ticket, marcar um artigo como lido ou guardado
- Executar um playbook: instanciar um modelo de plano guardado com os respetivos parâmetros. Isto apenas propõe um plano; nada é executado nem gasta até que um operador o aprove no Plan Studio num cliente completo
- Mudar de espaço de trabalho, a partir do seletor do próprio telemóvel
É praticamente tudo. Um telemóvel é um principal com menos privilégios do que um cliente completo. Não pode iniciar processos, gastar orçamento de LLM, fazer push para o GitHub nem criar espaços de trabalho. Consulte o modelo de acesso para saber como isto é imposto e não apenas pretendido.
Como a ligação é estabelecida
Secção intitulada “Como a ligação é estabelecida”A ligação assenta num relay intermediado: o servidor entra numa sala com
acesso por convite num broker wss:// como seu proprietário e cada cliente
emparelhado — computador, web, telemóvel — entra na mesma sala com um token de
admissão de duração limitada. Três peças concorrem para isto:
| Peça | Função |
|---|---|
| Remote (aplicação para telemóvel) | A aplicação web complementar, alojada por predefinição em remote.usectrl.dev, ou auto-alojada. É carregada num navegador e guarda o registo de emparelhamento no IndexedDB. |
| Broker do relay | Um relay wss:// sem estado (cc_signaling_server) que aloja salas de N participantes. Transporta apenas tramas opacas: cada carga útil é selada de ponta a ponta entre o telemóvel e o servidor, pelo que o broker nunca vê dados da aplicação nem o segredo de emparelhamento e nunca interpreta o que encaminha. |
cc_server |
O proprietário da sala. Responde às chamadas do telemóvel através do mesmo dispatcher que todos os outros clientes usam. |
Uma oferta de emparelhamento transporta um descritor de ligação que lista
todos os caminhos para o servidor (LAN, tailnet, wss:// público, relay) mais a
respetiva impressão digital de identidade. O resolvedor do telemóvel escolhe o
melhor caminho acessível e fixa a impressão digital na primeira ligação (TOFU);
o relay garante conectividade mesmo quando não existe nenhum caminho direto, sem
nunca conseguir ler o tráfego.
O que é a carga útil do emparelhamento
Secção intitulada “O que é a carga útil do emparelhamento”O emparelhamento é emitido a partir da aplicação e entregue como link direto; consulte Emparelhar um dispositivo para saber como proceder. O que importa aqui é a anatomia.
https://<pwa-host>/#<payload>A carga útil viaja no fragmento do URL, a parte a seguir a # que os
navegadores nunca enviam ao servidor, pelo que o anfitrião HTTPS da PWA nunca a
vê. Transporta tudo o que o telemóvel precisa para chegar ao servidor e provar
quem é: o descritor de ligação (todos os caminhos mais a impressão digital de
identidade), um id de dispositivo acabado de emitir, uma chave pré-partilhada de
32 bytes e uma marca de expiração. O telemóvel descodifica-a, guarda localmente
um registo de emparelhamento e remove o fragmento para que o segredo saia do
URL.
Existem duas formas de carga útil e não são intermutáveis. O QR para
telemóvel emitido a partir do painel de emparelhamento da aplicação é o
PairingPayload v2 acima, apontado ao anfitrião da PWA Remote. O comando
cc_server pair --client-url emite um link v1 diferente e mais antigo
({s, i, k} — URL do servidor, id do dispositivo, chave) destinado apenas ao
cliente web.
Também diferem no tempo de vida, o que é fácil de entender mal:
| Emitido por | Expiração da credencial |
|---|---|
Painel de emparelhamento da aplicação (pairing.mint) |
30 dias, sempre |
cc_server pair na linha de comandos |
Nenhuma — a credencial não expira |
O modelo de acesso
Secção intitulada “O modelo de acesso”Um dispositivo emparelhado é autenticado mas não fidedigno. Vários portões independentes impedem que um emparelhamento aprovado (ou divulgado) se torne controlo total do servidor.
1. A pertença, e não o emparelhamento, é a fronteira
Secção intitulada “1. A pertença, e não o emparelhamento, é a fronteira”Uma chave de emparelhamento válida prova que dispositivo está a comunicar. O que pode ler ou alterar é decidido pelo seu papel no espaço de trabalho, resolvido de novo em cada chamada, e por concessões por repo em tudo o que exponha conteúdo de repos. Um dispositivo que tenha uma chave perfeitamente válida mas pertença a um utilizador que não é membro do espaço de trabalho indicado é recusado com “Not a member of this workspace”.
O nível mínimo de papel deriva do tipo da operação, salvo se esta declarar o seu
próprio: as leituras exigem guest, as mutações exigem member e as operações
destrutivas exigem admin.
2. Um telemóvel é um nível de sessão inferior
Secção intitulada “2. Um telemóvel é um nível de sessão inferior”Para além da verificação de papel, uma sessão de telemóvel tem menos capacidade do que uma sessão de computador ou web. As operações declaradas como exclusivas de cliente completo são recusadas a um telemóvel antes de o handler ser executado, independentemente do quão privilegiado seja o utilizador por trás dele: emitir, listar, renomear e revogar emparelhamentos de dispositivos; ler e definir a conectividade do túnel; cópia de segurança do servidor e exportação/importação de espaços de trabalho; deteção e eliminação de processos; sondagens de adaptadores; definições do servidor; administração de SSO; controlo da frota; e assumir ou devolver um agente em execução.
3. Uma lista de permissões de ferramentas com negação por predefinição
Secção intitulada “3. Uma lista de permissões de ferramentas com negação por predefinição”Para a superfície de ferramentas MCP em concreto (tools/call), uma lista de
permissões com negação por predefinição determina quais as ferramentas que o
telemóvel pode invocar. Tudo o que não conste da lista é rejeitado antes de ser
executado. A lista é sobretudo de leitura e observação, mais um punhado de
escritas apenas locais — uma mensagem, uma atualização de ticket, uma
marcação de artigo — que não gastam orçamento de LLM, não iniciam processos nem
tocam em nenhum sistema externo.
São negados, por exemplo: consultar um agente, iniciar uma revisão com IA, eliminar um agente, publicar uma revisão no GitHub, contratar ou despedir agentes, criar um espaço de trabalho.
4. Âmbito de espaço de trabalho por chamada
Secção intitulada “4. Âmbito de espaço de trabalho por chamada”O servidor não guarda nenhum «espaço de trabalho atual». É sem estado por
conceção: cada chamada com âmbito de espaço de trabalho tem de indicar o
workspace_id de destino nos seus argumentos, e o dispatcher recusa
imediatamente a chamada quando este falta ou nomeia um espaço de trabalho que o
servidor não tem registado — antes de se abrir qualquer base de dados. Um
telemóvel nunca pode, por isso, herdar ou desviar-se para o âmbito de outro
cliente, e nomear um espaço de trabalho alheio também não ajuda, porque a
verificação de pertença do portão 1 continua a aplicar-se. Esta é a mesma
invariante de isolamento de espaços de trabalho que o resto do
produto impõe.
5. Tramas seladas de ponta a ponta com a chave pré-partilhada
Secção intitulada “5. Tramas seladas de ponta a ponta com a chave pré-partilhada”Todas as tramas entre o telemóvel e o servidor são seladas com a chave de emparelhamento; o token de admissão apenas coloca um cliente na sala e não decifra nada. O broker retransmite texto cifrado e nunca vê a chave. Um dispositivo revogado encontra a sua credencial já eliminada, pelo que falha de forma fechada ao reconectar.
Uma credencial emitida pela aplicação tem um prazo de 30 dias; depois disso, o portão de ligação rejeita-a e o telemóvel tem de voltar a emparelhar. A revogação é imediata: o servidor vigia a tabela de dispositivos e encerra as sessões abertas de um dispositivo revogado em segundos, em vez de esperar pela sua próxima ligação.
6. Limitação de pedidos por principal
Secção intitulada “6. Limitação de pedidos por principal”Um limitador de janela deslizante limita o tráfego de ferramentas remotas a 120 chamadas por minuto, com um sub-limite mais restrito de 30 por minuto nos verbos mutáveis. O orçamento pertence ao principal, e não à sessão: os seus três dispositivos partilham o mesmo limite, pelo que um cliente comprometido não consegue ganhar margem abrindo mais sessões e um membro ruidoso não consegue deixar os outros sem margem.
7. Um broker que nada fica a saber
Secção intitulada “7. Um broker que nada fica a saber”O broker de relay é deliberadamente simples: aloja salas, encaminha tramas seladas e não guarda contas, dados da aplicação nem chaves. As salas têm acesso por convite e são transitórias. Os dados da aplicação, o áudio, a transcrição, o código-fonte e as credenciais ficam todos no servidor.
Atualizações em direto
Secção intitulada “Atualizações em direto”Depois de emparelhado, o telemóvel recebe atualizações em direto sob a forma de tramas de notificação — novas mensagens de agentes, tickets atribuídos a si, alterações de estado — que espelham as notificações do próprio computador. O servidor difunde essas tramas a todas as sessões ligadas e o filtro de espaços de trabalho é aplicado do lado do cliente, pelo que o que vê fica limitado ao espaço de trabalho que está a consultar.
Onde se encontra
Secção intitulada “Onde se encontra”| Superfície | O que mostra |
|---|---|
Definições → Você → Seus dispositivos (/workspaces/:workspaceId/settings/you/devices) |
Clientes emparelhados com o estado em direto, mais Emparelhar um novo cliente (navegador web, aplicação de computador ou telemóvel) e revogar |
O mesmo painel emite emparelhamentos para um segundo navegador ou aplicação de computador, e não apenas para telemóveis — o fluxo é idêntico, só muda o link direto.
Ver também
Secção intitulada “Ver também”- Espaços de trabalho e isolamento: o âmbito por chamada em que isto se apoia
- Multijogador — identidade, pertença e presença: papéis, pertença e concessões por repo
- Implementação e clientes: onde o controlo remoto se situa entre os níveis de clientes
- Arquitetura: onde o controlo remoto se situa na pilha
- Emparelhar um dispositivo