Proposta · 16 out 2026 · substitui o viewer da 1ª versão do ADR-0343

Seu COGNIX[WS] em mais de um computador

A ideia do OneDrive aplicada ao COGNIX[WS]: o computador principal (o servidor) guarda o ambiente inteiro. Cada outro computador mantém uma cópia completa ou sob demanda e trabalha localmente, com os próprios CLIs e ferramentas. O que é feito lá volta sozinho para o servidor.

Funciona com o servidor desligado O agente usa o localhost e as ferramentas do computador onde roda O celular continua conectando só no servidor
Aguardando suas decisões — seção 6
1

A ideia: o OneDrive, peça por peça

Os dados moram num lugar; cada computador abre, edita localmente e devolve. No COGNIX[WS], o "lugar" é o seu computador principal e o "Excel" são os agentes.

No OneDrive
No COGNIX[WS]
Os servidores da Microsoft guardam os arquivos
O CASA-PC (computador principal) guarda workspaces, Inbox, missions, templates, artifacts e o histórico
O app do OneDrive no notebook mostra todas as pastas
O COGNIX[WS] do notebook mostra todos os workspaces, o Inbox e os agentes dos dois computadores
Arquivo "só online" (a nuvem)
Workspace só no CASA-PC: aparece na lista, mas o código não está no notebook
Abrir o arquivo baixa na hora
Open here clona o repositório na versão do CASA-PC
"Sempre manter neste dispositivo"
Always keep on this computer: o clone fica e se atualiza sozinho
"Liberar espaço"
Free up space: apaga a cópia local; o workspace continua na lista
O Excel abre e edita o arquivo localmente
O agente roda no notebook, com o CLI, o navegador e o Computer do notebook
O AutoSave devolve o arquivo ao servidor
O trabalho volta sozinho: Inbox e missions na hora; o código como branch no repositório do CASA-PC a cada fim de turno
Conflito: "Manter ambos"
Template ou workspace editado nos dois computadores: Keep both
Office ativado por dispositivo (até 5 PCs ao mesmo tempo)
Cada computador faz login nos seus CLIs; a conta passa a aceitar N computadores (decisão 9)
A diferença que importa: um agente é um processo, não um arquivo. Ele roda em um computador só — como uma janela do Excel aberta. Os outros computadores o veem ao vivo ("on NOTEBOOK"), mandam mensagem e podem trazê-lo para si (Continue here), mas nunca executam as ferramentas dele.
2

Como funciona

Os dois computadores têm o COGNIX[WS] completo. O app desktop de cada um continua falando com o próprio daemon, como hoje; quem passa a conversar são os daemons. já existe marca o que reaproveitamos; novo, o que falta construir.

CASA-PC computador principal
  • COGNIX[WS] completo, como hoje já existe
  • Fonte da verdade: o banco e os repositórios dos workspaces novo
  • Manda o push para o celular — um envio só
  • Roda automações, Channels e Calendar por padrão
  • Os agentes criados aqui rodam aqui
tailnet · HTTPS · credencial do computador novo
CASA-PC → NOTEBOOKas mudanças do servidor, pelo change feed, com cursor durável
NOTEBOOK → CASA-PCo que o notebook fez: fila local e branches git
NOTEBOOK computador sincronizado
  • COGNIX[WS] completo (WSL + daemon) que entra no seu ambiente novo
  • Sempre aqui: estrutura e trabalho
  • Sob demanda: código e histórico
  • Os agentes criados aqui rodam aqui, com o CLI, o navegador e o Computer daqui
  • Sem o CASA-PC: segue trabalhando; a fila espera
Celular (app web) — conecta só no CASA-PC e vê tudo, porque o CASA-PC tem tudo. Uma resposta dada no celular chega ao agente no computador onde ele roda. já existe

Dados

Cada evento do change feed já carrega o JSON da entidade (ADR-0048). O notebook segue o feed do CASA-PC e grava as próprias mudanças numa fila, na mesma transação do banco local. Mais de 7 dias offline: cópia completa.

Código

Git, nunca a sincronização de dados. Open here = clone do repositório do CASA-PC pelo vínculo (ou do GitHub, se o CASA-PC estiver fora). A branch do agente volta como notebook/<agente>; o merge acontece no Review/Merge, como hoje.

Execução

O agente roda onde foi criado. Logins de CLI, navegador do agente, Computer, VMs, terminais e confiança de pasta são de cada computador e nunca viajam.

3

Protótipos

Telas clicáveis. O texto das telas está em inglês, como no produto; as legendas em português explicam o que acontece. Os números são ilustrativos.

Você instala o COGNIX[WS] no notebook normalmente. Na primeira tela, em vez de começar do zero, ele entra no ambiente do CASA-PC com um código — o mesmo pareamento do celular.

Por baixo: o código vira uma credencial de computador, guardada só no notebook e revogável em Computers. O token de instalação do CASA-PC nunca sai de lá. A ligação usa o nome do CASA-PC no tailnet, que já tem certificado válido (ADR-0339).
4

O que sincroniza

Três classes. Toda tabela do banco cai em uma delas, e o CI recusa tabela nova sem classe (regra 3).

Sempre

Pequeno; chega quase na hora.
  • Estrutura dos workspaces: nome, origem git, setup, templates ligados
  • Templates e blueprints, skills, lista de extensões
  • Registro MCP, sem os segredos
  • Preferências, tags, snippets
  • Inbox, missions, mensagens, lembretes e agenda
  • Artifacts: lista, versões e comentários
  • Estado dos agentes e terminais de cada computador — para ver, não para rodar

Sob demanda

Grande; baixa quando você abre.
  • Código: clone git na versão do servidor
  • Arquivos dos artifacts
  • Conversas antigas, para o histórico e o Recall
  • Pacotes das extensões, da mesma fonte e versão
  • Imagens do Assistant
Cada um pode virar "Sempre" por workspace ou para o computador inteiro.

Nunca

É da máquina ou é segredo.
  • Processos, terminais, portas e dev servers
  • Navegador do agente e os logins dele em sites
  • Computer, VMs e Sandbox; WSL e disco
  • Confiança de pasta (é por caminho)
  • Logins dos CLIs e o cofre (por padrão)
  • Certificados, tokens e dispositivos pareados
Login com renovação rotativa não pode ter dois donos — é a regra de um renovador por login.
5

Regras de base

As que ficam caras de mudar depois. O resto da implementação pode crescer por partes sem retrabalho.

  1. O servidor é a fonte da verdade; cada computador trabalha numa cópia e devolve.Grava localmente primeiro, manda pela fila, e o servidor aceita pela versão.
  2. O agente roda onde foi criado.Com o CLI, o login, o navegador, o Computer e as VMs daquele computador. Sobre um agente, decide o computador onde ele roda.
  3. Todo dado tem uma classe: sempre, sob demanda ou nunca.O CI recusa tabela nova sem classe — como o inventário de backup já faz (ADR-0288).
  4. Identidade global antes de sincronizar.Hoje o id é nome + 6 hex (internal/store/store.go:143, 63 usos), único só no banco de cada computador.
  5. Os dados andam no change feed.Cada tipo ganha um codec que deixa de fora o que é da máquina (caminho, PID, porta).
  6. Código anda por git, nunca pela sincronização de dados.Branch no espaço do computador (notebook/*); merge no Review/Merge.
  7. Efeito externo tem um computador dono.Automações, push, Channels, Calendar e alertas de painel. Sem isso, um lembrete dispara duas vezes.
  8. Versão por tipo.Um computador desatualizado pausa só o que não entende e pede Update — o Remote já tem esse estado.
6

Decisões — o que recomendo

A 9 é comercial e só você decide. As outras têm uma recomendação; basta dizer OK ou mudar.

1
Modelo
O do OneDrive: o servidor guarda; os computadores sincronizam e trabalham localmente. O viewer sai; o celular continua sendo o cliente leve.
Funciona com o servidor fora do ar; o agente usa o localhost e as ferramentas de onde roda.
2
Padrão de sincronização
Estrutura e trabalho sempre; código, histórico e arquivos sob demanda; Always keep por workspace.
O notebook não precisa de 14 GB para começar; abrir um workspace é um clone.
3
Quem escreve
Grava local e manda pela fila; o servidor aceita pela versão; sobre um agente, decide o computador dele; definição alterada nos dois → Keep both.
Nada se perde offline; o conflito é raro e aparece para você.
4
Código de volta
A branch do agente volta ao repositório do servidor a cada fim de turno, no espaço do computador; o merge segue no Review/Merge.
O servidor vê o trabalho na hora, sem depender do GitHub. Alternativa: só pelo push ao origin.
5
Ligação
HTTPS no tailnet, pareamento por código e credencial de computador revogável; o SSH do Remote (ADR-0283) fica para VPS.
Sem sshd no Windows; o certificado do tailnet já existe (ADR-0339).
6
Remote e sincronizado
Um conceito só: Computers. Cada computador ligado é "Synced" (este modelo) ou "Remote" (o atual), com o mesmo seletor na sidebar.
Não ter duas páginas para "outro computador".
7
Efeitos externos
Automações, push, Channels e Calendar rodam no servidor por padrão; "Runs on" explícito para mudar.
Sem isso, uma automação dispara nos dois computadores.
8
Qual é o servidor
Fixo na v1 (o primeiro computador); "Make this the main computer" numa fase depois.
Trocar de servidor é uma migração de dados; não precisa existir no começo.
9
Conta e licença — comercial
N computadores por plano, listados na conta (o Microsoft 365 permite 5 PCs ao mesmo tempo).
Hoje o ADR-0300 permite uma sessão lógica por usuário: entrar no notebook derruba o CASA-PC.
10
Segredos
Logins de CLI nunca viajam; API keys do cofre: opcional numa fase depois, cifradas de ponta a ponta.
Um renovador por login: dois computadores com o mesmo refresh token se derrubam.
11
Detalhes
Nome do computador = nome do Windows, editável; credencial sem prazo até você revogar; indicador "Synced with CASA-PC · 2 min ago" no rodapé.
O rodapé do Remote já tem o indicador; o tray fica como está.
7

Fases

Primeiro as regras de base; o visível vem logo depois. Cada fase entra na main sozinha e deixa as anteriores funcionando.

F0
ADR-0343 reescrito, benchmark (OneDrive, Dropbox, Obsidian Sync, VS Code Settings Sync), tabela de classes com teste no CI, id global para dados sincronizados.
tabela nova sem classe quebra o CI.
F1
Conectar: Join my COGNIX[WS], código, credencial de computador, página Computers, indicador; o notebook vê os agentes do CASA-PC ao vivo.
um Windows limpo (VM) entra pelo tailnet e lista os agentes do CASA-PC.
F2
Trabalho sempre sincronizado: Inbox, missions, mensagens, lembretes; fila offline; push só do servidor.
a pergunta de um agente do notebook chega ao celular e a resposta volta, inclusive depois de um período offline.
F3
Estrutura: workspaces, templates, skills, registro MCP, preferências; Keep both.
toda linha da tabela de conflitos tem teste.
F4
Código sob demanda: Open here, Always keep, Free up space; a branch volta a cada turno; Review/Merge no servidor.
um agente do notebook gera uma branch revisável no CASA-PC.
F5
Efeitos externos com dono — e só então as automações sincronizam.
nenhuma automação dispara em dois computadores.
F6
Histórico e Recall sob demanda; gasto somado dos computadores.
uma busca no notebook acha uma conversa que só existe no CASA-PC.
+
Em paralelo — conta e licença com N computadores (cognix.ws e ADR-0300).
os dois computadores trabalham ao mesmo tempo com a mesma conta.
8

O que já existe e o que muda

Reaproveita

  • Pareamento por código e Devices (ADR-0049)
  • Certificado válido no nome do tailnet (ADR-0050, ADR-0339)
  • Remote (ADR-0283): seletor de computador, visão ao vivo, Inbox mesclada, Move agent, relay de login de CLI
  • Change feed com o JSON de cada entidade e cursor (ADR-0048)
  • Inventário de backup como modelo do inventário de sincronização (ADR-0288)
  • Review/Merge para o código que volta (ADR-0232)

Muda

  • A 1ª versão do ADR-0343 (o app desktop como viewer de outro servidor) sai. O app de cada computador continua ligado ao próprio daemon.
  • Fica uma correção pequena, que vale em qualquer modelo: só o app nativo em loopback deveria abrir o canal de comandos do navegador e do Computer. Hoje qualquer sessão pareada abre (internal/server/browser.go:425).
  • O notebook precisa da instalação completa (WSL + daemon): é o custo de rodar localmente.