Duas Maris,
um cérebro
só, um relógio

A garantia · crontab é por usuário

Hoje são 72 rotinas automáticas ativas, todas na crontab do usuário mari. A Mari K roda como um usuário novo, marik, e a crontab dela nasce vazia. Não é regra combinada, é como o Linux funciona: pra escrever na crontab do mari ela precisaria de crontab -u mari, que exige root, que ela não tem.

Descoberta que muda a conversa: nenhuma dessas rotinas passa pela sessão de agente nenhuma. São scripts do cron que escrevem direto em /opt/mari-bot/outbox/ ou chamam a API do Telegram. A Mari podia estar morta ontem e o briefing sairia igual.

VERIFICADO · li a crontab inteira e abri os scripts de rotina. morning-briefing.sh, lembrete-agenda-tarefas.py, mail_monitor.py, rastreio_monitor.py, consolidate-memory.sh e curate-skills.sh escrevem no outbox. chip_monitor.py, pg_saturation_monitor.py e check-meta-token.sh chamam a API do Telegram direto. Só o monitor-session-context.sh fala com o tmux, e nele a sessão está fixa como "mari" na linha 18.

A construir · três camadas, da mais forte pra mais fraca

1. Usuário separado. Estrutural. Ela não tem os jobs e não consegue tê-los. Nem que quisesse.

2. Outbox separado. Ela escreve em /opt/mari-bot-k/outbox. Se um dia ela decidir mandar um briefing por conta própria, ele chega no chat dela, numa conversa separada. Fica óbvio e visível, nunca vira um duplicado confuso no mesmo fio.

3. O delta dela em /home/marik/.claude/CLAUDE.md. Umas dez linhas: as rotinas de relógio não são suas, você nunca inicia nada por horário, você só age quando o Chefe pede. Esse arquivo é lido além do CLAUDE.md do projeto, então não suja o compartilhado.

Digo com todas as letras: a camada 3 é instrução, e instrução é exatamente onde o Kimi é pior. É por isso que ela é a terceira, e não a primeira. As camadas 1 e 2 não dependem de ela ler nada.

Por que as outras saídas falham

• Rodar as duas no mesmo usuário e marcar quem é numa variável de ambiente: a variável é rótulo, não trava. Não muda o comportamento de nenhuma rotina, porque as rotinas nem olham pra sessão. E não impede o modelo de ler o arquivo e agir.
• Seção condicional no CLAUDE.md compartilhado (algo como "se você é a Kimi, ignore isto"): falha pelo mesmo motivo e piora o arquivo pras duas. Instrução condicional é o tipo de coisa que modelo de fora segue pior.
• Mesmo usuário: resolveria o cron, porque a crontab é uma só e roda uma vez de qualquer jeito. Mas joga fora a única garantia estrutural que existe de graça, e cria problema novo: as duas sessões brigando pelo mesmo ~/.claude, com histórico e snapshots compartilhados.

O que ajuda sem restringir nada

Como as duas gravam no mesmo conversation_history, no boot e a cada turno cada uma vê o que a outra está fazendo. Uma linha no CLAUDE.md resolve o resto: antes de começar tarefa longa, olhar as últimas trocas da outra e avisar se for a mesma. Isso não bloqueia nada, ele continua mandando o que quiser pra quem quiser.

O banco aguenta · verificado

• conversation_history: chave primária por sequência, sem restrição de unicidade, sem leitura antes de escrever. Duas gravando ao mesmo tempo é seguro por construção. seguro
• A API da porta 3007: só faz SELECT e gera o vetor da consulta na hora. Não guarda cache em memória, não escreve nada. As duas podem consultar à vontade. seguro
• memory_chunks, o índice vetorial: aqui não é seguro pra dois escritores. O index_knowledge.py faz DELETE ... WHERE source_file= e depois INSERT, e a tabela tem restrição de unicidade em (source_file, agent_id, chunk_index). Dois indexadores ao mesmo tempo colidem ou apagam o trabalho um do outro. um só
• embed_conversations.py: dois rodando não corrompem, mas fazem o trabalho em dobro e a OpenAI cobra duas vezes. um só

Os dois últimos são cron do mari. Como a crontab é por usuário, resolvem sozinhos: a Mari K nunca os terá.

VERIFICADO · li o esquema das tabelas no banco, o index_knowledge.py (linhas 71 e 76) e o memory-api/server.py inteiro. O índice tem 3.858 pedaços hoje.

O que quebra: caderno único

pending.md, decisions.md, projects.md, lessons.md, people.md e as notas de daily/ são arquivo único. Duas escrevendo é lost update silencioso: a segunda salva o arquivo inteiro e a anotação da primeira some, sem erro, sem log, sem ninguém saber. E não é teórico, é o padrão de uso: quando um item vira arquivado, o arquivo inteiro é reescrito.

Some no arquivo e some no índice vetorial junto, porque o indexador reconstrói a partir do arquivo. É o defeito mais caro possível: memória perdida sem barulho.

A construir · a migração

Cabeçalho mínimo de cada ficha, pra o índice conseguir montar sozinho:

---
id: pend-2026-09-04-chave-kimi
titulo: Chave da API do Kimi
estado: aberto        # aberto | feito | arquivado
criado: 2026-09-04
por: mari             # quem escreveu
---

Considerei append-only e descartei

A outra saída era log só de acréscimo, com um consolidador de hora em hora. Ganha em segurança bruta, porque acréscimo de linha curta no Linux é atômico e nunca perde. Perde no que importa aqui: pra saber o estado atual você teria que reduzir o log inteiro, e esses arquivos são lidos no boot das duas. Boot fica mais caro e mais frágil, e o git já dá o histórico que o append-only daria.

Fica um híbrido: as notas de daily/ viram só acréscimo, uma por agente. Nota do dia é log por natureza, então ali o formato certo é log.

Já pronto · nada a construir

E tem um detalhe que faz isso funcionar sozinho: a consulta de boot do CLAUDE.md não filtra por sessão. Ela é ORDER BY created_at DESC LIMIT 30, sem WHERE. Basta o bot novo gravar na mesma tabela e cada uma lê a conversa da outra de graça, no boot e sempre que quiser.

Uma correção pequena e obrigatória: os 185 arquivos da auto-memória ficam dentro da pasta pessoal, em /home/mari/.claude/projects/-opt-mari/memory/. Usuário novo teria a dele, vazia. Um link simbólico resolve, e aí as duas veem o índice inteiro.

Verificado no código, linha por linha

bot.py:901 grava o lado user dentro do handle_update, antes de injetar no tmux. bot.py:1195 grava o lado assistant dentro do outbox_loop, depois do Telegram confirmar 200. A sessão do Claude Code não escreve nessa tabela em momento nenhum.

VERIFICADO · grep save_history bot.py devolve 5 linhas, sendo 2 chamadas reais. O banco confirma: 8.291 registros assistant e 4.508 user em telegram-dm, com a última troca de hoje íntegra.

Onde ainda tem furo, com nome

• O que ela pensou e não publicou morre junto: raciocínio, plano de cabeça, meia tarefa.
• Resposta escrita no outbox que o bot não chegou a enviar não vira histórico, porque o registro só acontece depois do 200 do Telegram.
• Arquivo escrito pela metade fica pela metade.

É por isso que a ficha de pendência continua importando: ela guarda intenção. O histórico guarda o que foi dito.

O que eu recomendo proteger mesmo assim

O Chefe decidiu liberdade total, sem separar credencial, e é decisão dele. Só que existe um cenário que vale ele conhecer, porque conhecimento idêntico piora ele:

As duas leem a mesma ficha, veem a mesma medição, chegam à mesma conclusão correta e as duas disparam. O grupo recebe a mensagem duas vezes. Não é bug de nenhuma das duas: as duas fizeram a coisa certa com a mesma informação.

A proteção que eu proponho não restringe ninguém: em vez de tirar credencial de alguém, colocar idempotência no disparador. O disparo já tem estado de quem recebeu; o job passa a recusar repetir a mesma mensagem pro mesmo número na mesma janela, venha de quem vier. Assim as duas continuam com liberdade total e o grupo fica protegido pela máquina, não pela memória de quem mandou.

NÃO CONFERI se os disparadores atuais já têm essa trava. Não abri nada em /opt/leads-maringa, que está com duas mensagens armadas pra hoje à noite. Fica como pergunta pra depois do disparo de hoje, não como afirmação.