[🛠] Troquei o Cell que seria um Linux Container por um usuário do macOS

✨ Resumo do GPT-5.6 Sol

Um registro de abandonar o plano que usava uma Linux VM e Containers por usuário como padrão e redefinir a unidade de execução como um usuário do macOS por funcionário com OpenClaw native.

Revirei a estrutura básica em apenas um dia

Ontem, conectei um coordenador e vários workers na prática. Experimentei uma forma de separar os resultados produzidos por várias IAs em Worktrees, Branches e commits, para depois reuni-los novamente.

Ao mesmo tempo, eu também preparava o ambiente de execução do AI Orchestration. Até o dia 14, a estrutura básica era esta:

Mac mini
→ 1 Colima Linux VM
→ OpenClaw Cell Containers por funcionário

Criar uma Image comum e separar Network e Volume para cada funcionário parecia facilitar o deploy e a reprodução do ambiente. Eu já tinha confirmado a Image oficial Linux arm64 do OpenClaw e criado um child Image e um contrato de Cell Network. A direção de separar o ambiente de cada funcionário em Containers já estava bastante concreta.

Mas, no dia 15, retirei essa estrutura da proposta padrão.

O que eu queria construir não era um serviço de Containers

Quando reescrevi o objetivo do AI Orchestration, percebi o desalinhamento.

O que eu queria criar era um ambiente em que os funcionários apenas informassem seus objetivos pelo WebChat, e uma IA pessoal dividisse as tarefas necessárias, escolhesse as ferramentas e conduzisse o trabalho até o fim. Não se tratava apenas de produzir código e documentos. A IA precisava controlar apps do Mac, executar Xcode e Simulator e deixar resultados reais usando o Workspace e a Git identity do usuário.

A estrutura fica estranha no momento em que tentamos forçar um Linux Container a chamar recursos do macOS. Seria preciso manter um executor separado fora do Container, reconectar permissões e estados e transmitir o Keychain e a GUI Session do usuário. Por causa da camada criada para isolamento, as funções realmente necessárias passariam a depender o tempo todo de rotas alternativas.

O OpenClaw também não era um simples stateless worker. Ele se parecia mais com um ambiente pessoal que reúne o Gateway, Profile, Session, Memory, OAuth e o estado de execução de um usuário. Nesse caso, talvez o erro estivesse na própria definição de Cell como um Container.

No dia 15, redefini o significado de Cell.

1 funcionário
= 1 usuário do macOS
= 1 OpenClaw Gateway independente
= 1 conjunto de UID·HOME·Keychain
= 1 conjunto de ChatGPT OAuth·CODEX_HOME
= 1 conjunto de Workspace·Git identity·Session·Memory

A nova estrutura cria um usuário independente do macOS para cada funcionário em um único Mac mini e executa um OpenClaw Gateway completo de forma native dentro de cada usuário.

Mantive os Containers como sandbox opcional

O experimento com Containers trouxe constatações claras. As evidências sobre a Image oficial, execução non-root, root read-only, separação de Network, fronteiras de Volume e credentials, Image provenance e restart continuavam valiosas.

A Linux VM e os Containers deixaram de ser o ambiente padrão do Pilot e passaram a ser candidatos a sandbox apenas para tarefas específicas que realmente exigissem isolamento. O macOS native virou o padrão; o Container, uma ferramenta a ser usada quando sua necessidade fosse comprovada.

Separar usuários do macOS também não encerrava o isolamento

A estrutura native parecia simples, mas havia ainda mais coisas a verificar.

• o funcionário conectado e o usuário real do macOS que executa o processo são a mesma pessoa?
• o Gateway, o OAuth, o Workspace e o autor Git desse usuário estão vinculados corretamente?
• quando a autenticação de um usuário falha, o sistema evita recorrer à autenticação de outro?
• um usuário não consegue acessar HOME, Keychain, Port e Workspace de outro?
• depois de uma troca rápida de usuário ou de um reboot, cada Gateway recupera seu próprio estado?

Por isso, não parei depois de apenas alterar a topology nos documentos. Criei um novo contrato e uma nova Acceptance para o native macOS Cell e deixei como NOT_READY os itens sem evidência real de Runtime.

O fato de um test fixture passar também não significava que o isolamento entre dois usuários reais estivesse concluído. Separei o hash dos arquivos de entrada externos das evidências de execução dos probes reais e continuei corrigindo o sistema para impedir que a verificação fosse contornada por valores que imitassem outro usuário, symlinks ou aliases de caminhos do macOS envolvendo maiúsculas, minúsculas e Unicode.

Depois de mudar a topology ao meio-dia, passei a tarde fazendo commits para fechar “brechas que permitiam mentir dizendo que o teste passou”. Mais código foi necessário para tornar honestas as condições de aprovação da nova estrutura do que para mudar a própria estrutura.

Também separei os Workflows comuns do estado pessoal

Mesmo que cada funcionário recebesse um ambiente totalmente independente, os Workflows comuns gerenciados pela empresa precisavam ser distribuídos na mesma versão. Por outro lado, uma atualização desses Workflows não deveria alterar OAuth, Memory ou Workspace pessoais.

Na tarde do dia 15, fixei cada Workflow Release por version e content hash e criei um contrato de admission que permitia selecionar somente releases validados. A seleção de um novo release precisava mudar de forma atômica; as tarefas em execução deveriam permanecer vinculadas ao release escolhido no início; e nenhum release em uso poderia desaparecer durante rollback ou limpeza.

Também nesse caso, eu não registrei como instalado no local compartilhado do Mac algo que existia apenas em Source e testes. Um Runtime ainda não instalado permaneceu NOT_READY até o fim.

Ambiente de execução padrão e verificações pendentes

• Cell padrão: um usuário macOS native e um OpenClaw Gateway independente por funcionário
• isolamento opcional: Linux Container sandbox apenas para tarefas cuja necessidade seja comprovada
• estado comum: Workflow release fixado por version e content hash
• estado pessoal: OAuth, Memory, Workspace, Git identity e Session
• isolamento real de Runtime entre vários usuários: NOT_READY

O que ficou definido no dia 15 foi a topology. O isolamento real entre dois usuários e a instalação do Workflow comum ainda precisavam ser confirmados com evidências de Runtime.