Respostas
O conhecimento do time deve morar em arquivos versionados ou em memória curada?
Arquivos no repositório — um CLAUDE.md, uma pasta de skills, anotações commitadas ao lado do código — são onde a maioria dos times coloca o que a IA precisa saber, e resolvem bem o que é do repositório: convenções, comandos, o formato do código. O que eles não carregam é a parte que muda e precisa de gente atrás — qual regra está em vigor, quem decidiu, se é proposta ou coisa sancionada, e se o modelo de fato recebeu aquilo. É essa parte que o Arroway trata como material de produto: curada por pessoas, ranqueada contra a tarefa e entregue com um recibo dizendo quanto coube.
Arquivo se corrige na mão, e só depois que alguém percebe
Um arquivo versionado está atualizado até onde a última pessoa lembrou de editá-lo. Nada avisa que uma linha foi superada — regra revogada se lê igual a regra viva, e segue sendo obedecida até um humano escrever a correção. No Arroway isso é funcionalidade, não tarefa: cada memória nasce com a condição que a mata, memória superada aponta para a que a substituiu, e proposta espera uma pessoa em vez de governar calada.
Repositório é uma fronteira, e metade do time vive fora dela
Conhecimento dentro de um repo alcança quem trabalha naquele repo. A decisão de preço, a regra do que pode ser dito a um cliente, o motivo de um fornecedor ter sido cortado — tudo isso é do mesmo time e não tem repositório onde morar, e quem carrega essas coisas muitas vezes nem abre um. O Arroway recorta por projeto, não por base de código: decisão escrita por quem nunca toca no git chega ao assistente de quem toca.
Carregar um arquivo não é saber que ele chegou
Arquivo é texto posto na frente do modelo, e quanto dele coube não é algo que o próprio arquivo consiga informar. A leitura do Arroway é ranqueada contra a tarefa declarada e volta dizendo quanto do orçamento usou e o que ficou de fora — então "a IA tem a regra" deixa de ser suposição e vira algo conferível. Esse recibo é a diferença entre contexto que foi enviado e contexto que chegou.
Como isso aparece na prática
Um time escreve a regra de publicação no arquivo de contexto do repositório. Dois meses depois a regra muda numa reunião e ninguém toca no arquivo — todos os assistentes seguem citando a regra antiga, corretamente, a partir de um arquivo que ninguém achava desatualizado. A falha não é alguém ter esquecido: é o arquivo não ter como dizer que foi superado.
Perguntas que as pessoas fazem sobre isso
- Então a gente apaga os arquivos de contexto?
- Não, e o Arroway não pede isso. Arquivo continua bom no que é do repositório: como construir, como rodar, as convenções do código. O que muda de lugar é a parte que tem um humano atrás e muda sem o código mudar. O próprio repositório do Arroway mantém um arquivo de contexto por esse motivo, e deixa regra e decisão fora dele de propósito.
- E se a gente commitar as decisões também, com data?
- Dá pra fazer, e times fazem. O que um arquivo commitado continua sem conseguir é separar proposta de decisão sancionada, dizer ao assistente qual de duas linhas conflitantes vale, ou informar quanto do arquivo o modelo recebeu de fato. São as três falhas de que esta página trata, e nenhuma se resolve escrevendo com mais capricho.
- Na prática, o que uma pessoa precisa fazer pra manter isso em dia?
- Revisar, não redigir. Os assistentes propõem o que aprenderam como propostas; uma pessoa sanciona, corrige ou descarta, e só o que um humano sancionou governa. O trabalho é julgar uma lista curta, não lembrar de anotar.
Onde isto se confere
Documentação do produto neste site (Como funciona, Instalar) e a spec sancionada no repositório. A descrição de arquivos-no-repositório fala da prática, não do produto de nenhum fornecedor, e toda propriedade citada aqui é de um arquivo versionado comum: sem vigência, sem etapa de sanção, sem recibo de entrega. Esta página não afirma nada sobre a memória nativa de nenhuma ferramenta de IA específica.
https://www.arroway.app/pt-BR/answers/context-files-vs-curated-memory