9 Blocos de Construção para Executar o Claude Code como um SO Persistente em 18 Negócios

Um desenvolvedor no r/ClaudeAI descreve a execução de 18 instâncias do Claude Code não como projetos isolados, mas como instâncias de um sistema operacional compartilhado. Cada instância executa um negócio diferente (estratégia, produto, site de marketing, inteligência de ameaças, três clientes de consultoria, marca pessoal), todas compartilhando um esqueleto comum que é atualizado uma vez e propagado seletivamente.

Os 9 Blocos de Construção

1. Construir um esqueleto com propagação seletiva

• Em vez de construir um projeto por workspace, o desenvolvedor construiu um template contendo plugins, regras, agentes, hooks, esquemas e comandos.
• Ao iniciar um novo negócio, o template é clonado. Cada instância herda todo o SO, mas diverge em arquivos canônicos, memória, saída e estado do projeto.
• A CLI de atualização sincroniza plugins, regras, agentes, hooks e esquemas; nunca toca em memória, saída, canônico ou meu-projeto (esses acumulam por instância).

2. Mover o estado dos prompts para o código

• LLMs são ruins em lembrar; código é feito para isso. Estado como regras de voz, preferências de estilo, palavras proibidas e decisões recentes foi movido para servidores MCP.
• Linter de voz, pontuador de leads, validador de agenda, rastreador de loops rodam em Python e retornam dados estruturados.
• Regra prática: se você explicou algo ao Claude mais de duas vezes, deveria ser código.

3. Usar recibos, não campos de status

• Campos de status (issue fechada, PRD enviado, teste passando) não são confiáveis porque o LLM pode alegar qualquer coisa.
• Fluxos de trabalho foram reconstruídos em torno de recibos — um script escreve um registro de verificação antes que uma issue possa ser marcada como verificada. O modelo não pode mentir sobre se o código foi executado.

4. Construir uma barreira de verificação de integração

• Funcionalidades meio construídas apodrecem silenciosamente em repositórios de IA porque nada quebra.
• Um comando /wiring-check foi construído. Antes de uma tarefa ser concluída, ele verifica se toda nova habilidade tem um trigger, se todo novo hook está em settings.json, se toda nova ferramenta MCP está no servidor, se todo novo arquivo de barramento tem um produtor e um consumidor.
• "Acho que funciona" falha na barreira. "Executei X, obtive Y" passa.

5. Fazer as regras carregarem automaticamente, não comandos de barra

• Regras em .claude/rules/ carregam automaticamente. A regra de voz dispara em texto de saída, a regra AUDHD em qualquer coisa acionável, a regra de reação social ao compartilhar post de outra pessoa.
• Não é preciso memória ou força de vontade.

6. Aplicar lint no estilo em código, não em prosa

• Um documento de voz era ignorado pelo Claude metade das vezes. A lista de palavras proibidas foi movida para um scanner Python que bloqueia travessões, palavras de hype de IA e mais de 40 outros indicadores.
• "O modelo não consegue argumentar contra uma regex."

7. Rastrear dependências de arquivos com um grafo

• Arquivos canônicos referenciam uns aos outros. Um ripple-graph.json mapeia dependências. Editar talk-tracks sinaliza current-state e o playbook de engajamento para revisão.

8. Encadear sessões com handoffs e memória

• "Sessões são rascunhos. O trabalho é tudo que sobrevive à sessão."
• Cada sessão termina com /q-wrap, que escreve um documento de handoff, uma atualização de memória e um recibo de status. /q-morning lê todos os três.

9. Tratar o ambiente como substrato, não como editor

• A maioria dos desenvolvedores trata o Claude Code como um editor mais inteligente. A mudança ocorre quando você para de pensar em sessões como unidade de trabalho e começa a pensar em todo o ambiente como um substrato sobre o qual construir.

Esta abordagem é voltada para desenvolvedores que desejam escalar o Claude Code em vários projetos sem duplicação ou vazamento de estado. O tópico completo inclui discussão de detalhes de implementação e as compensações.