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.

Não apaguei Linux e Containers como se fossem um fracasso

Mudar de direção não significava tratar como fracasso tudo o que eu tinha construído até o dia 14.

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.

Mas elas não definiam o Cell final.

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.

Essa diferença era importante. Se eu continuasse insistindo na estrutura de Containers apenas porque já tinha investido muito tempo nela, o produto acabaria sendo conduzido pelo ambiente de execução. A quantidade implementada não justificava a escolha.

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.

O produto vinha antes do ambiente de execução

No dia 14, pensei em como dividir e integrar várias IAs. No dia 15, voltei a pensar no que seria o Cell onde essas IAs realmente viveriam.

Não foi fácil abandonar os Containers depois de já ter preparado tanta coisa. Mesmo assim, se o produto precisava trabalhar com apps do macOS, Xcode, OAuth e Memory de cada usuário, o ambiente de execução também precisava seguir esse objetivo.

Um Cell não era apenas um processo isolado. Era um ambiente completo de IA pessoal, no qual uma pessoa trabalha com a própria autenticação, memória, espaço de trabalho e ferramentas.

O dia 15 foi quando decidi parar de empilhar Containers sobre uma Linux VM e usar o próprio usuário do macOS como fronteira de cada Cell.