User Intelligence

Workspace Intelligence guarda o projeto. User Intelligence guarda a pessoa por trás do trabalho.

Dois engenheiros no mesmo repositório não querem a mesma coisa de um agente, e a diferença não é cosmética. Ela está em quanto o agente deve decidir sozinho, em quando ele deve parar e oferecer opções em vez de implementar, em quanta verificação é suficiente e em qual caminho seguir quando dois designs são igualmente defensáveis.

Isso é um corpo real de conhecimento e, sem um lugar para guardá-lo, ele vive nas correções que você digita de novo a cada nova sessão.

O que ela modela

Preferências de execução

Se você quer uma refatoração incremental ou está aberto a uma reescrita. Se espera ver opções antes de uma implementação ou prefere que o agente simplesmente siga em frente em determinado tipo de mudança. Quanta abstração você considera justificada. Sobre quais tipos de mudança você espera ser consultado antes que aconteçam.

Padrões de decisão

Quais trade-offs você costuma escolher. Desempenho contra manutenibilidade. Construir contra adotar. O quanto você leva a sério a compatibilidade com versões anteriores. O que você pesa primeiro quando uma decisão de produto atravessa o caminho de uma decisão técnica.

Expectativas de qualidade

Quanto teste você espera. Quando você quer um benchmark em vez de um argumento. Quando a pesquisa é suficiente e quando ela virou um substituto para entregar. O que você entende por pronto e qual nível de validação vem junto.

Estilo de colaboração

Quão autônomo o agente deve ser. Quando você espera uma pergunta. Quando espera poder escolher. Como você quer que o trabalho seja reportado e com que densidade de explicação.

O que ela não modela

Não quem você é. Nada de dados demográficos, nada de personalidade, nada inferido sobre você como pessoa. A unidade é uma preferência de trabalho sobre como o trabalho de software deve ser feito, e cada uma delas é algo que você poderia ter dito em voz alta.

Três tipos de afirmação são recusados de cara em vez de armazenados:

• Qualquer coisa pessoal. Saúde, religião, política, sexualidade, etnia, finanças e relacionamentos privados estão fora do que o Pathrule guarda, seja qual for o assunto da frase.
• Uma regra disfarçada de preferência. Uma preferência é um conselho para um agente. Uma afirmação formulada como proibição ("nunca", "não deve", "proibido") seria lida como um requisito do projeto, coisa que ela não tem autoridade para ser, então não é armazenada. Se algo realmente nunca pode acontecer em um projeto, isso pertence ao projeto, como uma regra.
• Um fato sobre um projeto. "Neste repositório usamos o helper de configuração compartilhado" é verdade para uma base de código, não para você. Armazenado como seu, isso iria com você para o repositório de um cliente, onde está errado. Isso é conhecimento do espaço de trabalho e fica com o espaço de trabalho.

Como ela aprende

Você a ensina. Rode pathrule me teach com a frase que você continuaria digitando em novas sessões:

pathrule me teach "Show me options before implementing anything that changes a public API"

O modelo local opcional lê a frase na sua própria máquina e a transforma em uma preferência de trabalho estruturada. Seja qual for a conclusão dele, ela precisa estar presente nas suas próprias palavras: ele não pode parafrasear você até chegar a uma preferência que você nunca expressou e, quando não consegue apontar o que você escreveu, nada é armazenado e o CLI explica o motivo.

What you teach
      |
Checked against your own words
      |
Refused, or stored as a preference
      |
Active, and delivered where it applies

Na prática, se você vive repetindo alguma versão de "não transforme toda implementação em um projeto de pesquisa", a representação útil não é uma citação salva. É uma preferência de trabalho:

Prefer implementation once the primary correctness
questions are resolved.

Source:     you told Pathrule
Applies:    across workspaces

Ensinar exige um Mac com Apple Silicon e o modelo local instalado. Todo o resto desta página, incluindo a entrega, funciona sem ele.

Mudando de ideia

Quando você ensina uma nova preferência que contradiz uma anterior sobre o mesmo tipo de trabalho, a nova substitui a antiga. A antiga é desativada, não apagada, e mantém uma referência ao que a substituiu, então a pergunta "por que isso mudou" sempre tem resposta. Duas preferências sobre tipos de trabalho diferentes simplesmente valem as duas.

Quem é "o usuário"

As preferências são escritas sobre você, então, quando você fala das pessoas que usam o que você constrói, a redação poderia transformá-las silenciosamente em você. "Resolva as coisas sem mostrar erros aos usuários" seria lido por um agente como "não me mostre erros", o oposto do que você quis dizer. Quando as suas palavras eram sobre os seus usuários, a preferência continua dizendo "usuários finais".

Onde uma preferência vale

User Intelligence pertence a você, não a um repositório. Onde cada preferência vale é outra questão.

• O que você ensina vale em todo lugar. Não foi aprendido a partir de um projeto, então não fica guardado em um.
• Você pode restringir uma preferência a um espaço de trabalho. pathrule me scope <id>, executado dentro de um repositório, restringe essa preferência ao espaço de trabalho em que você o executou. pathrule me scope <id> --everywhere faz com que ela volte a valer em todos os espaços de trabalho.

Como uma preferência chega a um agente

Antes de cada turno, o Pathrule escolhe as preferências que se aplicam ao trabalho que está para acontecer.

• Só as ativas. Uma preferência que ainda não está em uso aparece em pathrule me list e nunca chega a um agente. As desativadas e as rejeitadas também não são usadas.
• Só as que estão no escopo do espaço de trabalho, como descrito acima.
• Só as que dizem respeito a esta tarefa. Uma preferência sobre como trabalhar com você vale para qualquer tarefa. Uma preferência sobre um tipo de trabalho, como arquitetura ou migrações, só chega a um agente quando a tarefa é sobre isso.
• Um número pequeno por turno, das mais fortes para as mais fracas. Se houver mais aplicáveis, as mais fracas ficam de fora.
• Cada uma informa de onde veio, para que o agente possa dar a "você disse isso" o peso que isso tem.

Elas chegam pelo hook de prompt, cada uma uma vez por sessão, sob um título que avisa o agente de que as regras e as verificações obrigatórias do espaço de trabalho vêm primeiro. Hoje isso significa sessões do Claude Code e do Codex. Cursor e GitHub Copilot têm hooks de sessão e de ferramenta, mas não têm hook de prompt, e o Windsurf não tem hooks, então as preferências não chegam a eles. Veja como os hooks funcionam.

Autoridade: o que acontece quando você e o projeto discordam

Uma preferência do usuário não se sobrepõe à verdade do projeto.

User Intelligence
Prefer minimal testing.

Workspace Intelligence
Rule: run migration verification before completion.

A regra vale. Ela é um requisito do espaço de trabalho, e uma preferência por menos verificação não é motivo para descartá-la.

O princípio geral, que vale a pena dizer com todas as letras:

• Workspace Intelligence representa a verdade e os requisitos do projeto. As regras e as verificações obrigatórias dela são requisitos rígidos.
• User Intelligence molda a colaboração: como o trabalho é abordado, quanto é feito de forma autônoma, como é reportado. Ela não redefine o que significa estar correto.

Quando as duas tratam apenas de estilo, a sua preferência vale. Quando o espaço de trabalho declara um requisito de segurança ou de correção, esse requisito se mantém.

O mesmo vale mesmo sem uma regra do espaço de trabalho. Uma preferência que possa significar menos verificação é retida sempre que o trabalho envolve autenticação, pagamentos, migrações de dados, criptografia ou segurança. Erros nessas áreas são silenciosos e caros, e uma preferência formada em código do dia a dia não diz nada sobre ser seguro aplicá-la ali.

O que você controla

Tudo. User Intelligence é inspecionável, não implícita. Para cada preferência, você pode ver:

• O status: candidata, ativa, desativada ou rejeitada.
• De onde ela veio e qual o grau de confiança.
• Onde ela vale: em todos os espaços de trabalho ou só em um.
• Por quê: as palavras em que ela se baseia, com datas.

E você pode:

• Ensinar uma preferência diretamente.
• Esquecer uma. Ela deixa de ser usada e fica guardada como rejeitada, para que a mesma afirmação não a traga de volta na hora. Adicione --delete para removê-la por completo.
• Restringir uma a este espaço de trabalho ou deixar uma valer em todo lugar.
• Conferir o que um agente receberia para uma tarefa antes de começá-la.

Uma inferência que você nunca vê é uma inferência que você não pode contestar, e é por isso que cada preferência está a um comando de distância.

Pela linha de comando

pathrule me list                    # what is in use, and what is not yet
pathrule me teach "I prefer incremental refactors"
pathrule me explain <id>            # the evidence behind one preference
pathrule me scope <id>              # keep it to the workspace you run this in
pathrule me scope <id> --everywhere # let it apply in every workspace
pathrule me forget <id>             # stop using it
pathrule me forget <id> --delete    # remove it entirely
pathrule me context "add a payments webhook"

pathrule me context mostra exatamente o que um agente receberia para aquela tarefa, além de quais preferências foram retidas e por quê. É o jeito mais rápido de conferir que uma preferência chega ao trabalho para o qual você a pensou, e só a esse trabalho. Todos os subcomandos aceitam --json.

Mudando de projeto

Abra outro repositório e o conhecimento de projeto ao seu redor muda por completo. As preferências que você ensinou, a menos que tenha restringido alguma a um único espaço de trabalho, vão com você.

É aí que as duas se encontram em um turno: o espaço de trabalho contribui com o que é verdade e obrigatório ali, você contribui com como o trabalho deve ser feito, e a entrega mantém os requisitos do projeto acima das suas preferências. Veja Agent IR.

Limites que vale conhecer

• A correspondência é por palavras, não por significado. Uma preferência chega a uma tarefa que compartilha os mesmos termos. Uma preferência formulada de um jeito muito diferente da tarefa pode não ser aplicada.
• Ensinar exige o modelo local, que só roda em Macs com Apple Silicon.
• As preferências só chegam a clientes com hook de prompt: Claude Code e Codex.
• Ela se abstém em vez de adivinhar. Uma frase que ela não consegue fundamentar nas suas próprias palavras não é armazenada. Deixar de registrar uma preferência custa a você mais uma frase; inventar uma faria você ser mal representado para todos os agentes com que trabalha.

Privacidade

A inferência que transforma o que você ensina em uma preferência estruturada roda no seu próprio dispositivo, e as suas preferências ficam guardadas em um armazenamento privado na sua máquina.

Se você compartilha um espaço de trabalho com uma equipe, o que é sincronizado é o conhecimento do espaço de trabalho, não as suas preferências pessoais de trabalho. E, quando você roda o Claude Code, o Codex ou outro agente, os limites do provedor desse agente se aplicam a tudo o que chega a ele. A página de segurança mantém esses limites separados, porque juntá-los em uma única frase é justamente o que faz uma afirmação deixar de ser verdadeira.

O que ler em seguida

• Workspace Intelligence: com o que o projeto contribui e por que os requisitos dele prevalecem.
• O modelo local: o que roda no seu dispositivo e como instalá-lo.
• Referência de comandos do CLI: todos os subcomandos de pathrule me junto com o restante do CLI.