Workspace Intelligence

A Workspace Intelligence é a resposta a uma única pergunta: como este projeto funciona?

Não se trata do que os arquivos contêm. Isso o agente consegue ler, e lê bem. O que ele não consegue ler é o conhecimento prático que um repositório acumula em torno do código, e é justamente esse conhecimento que decide se uma mudança está correta ou apenas parece plausível.

O que ela modela

• Decisões de arquitetura, e o raciocínio que levou a elas.
• Restrições ocultas que não aparecem em lugar nenhum do código.
• Requisitos de verificação: o que precisa ser checado antes de algo ser considerado pronto.
• Correções anteriores: o que de fato funcionou na última vez que esse problema específico apareceu.
• Convenções que a equipe segue sem nunca ter escrito.
• Procedimentos: a sequência em que uma tarefa recorrente é feita aqui.
• Fatos contextuais que mudam a abordagem certa, como um banco de dados ser uma réplica somente leitura.
• Justificativas técnicas, que impedem o agente de desfazer, com a melhor das intenções, uma decisão tomada de propósito.
• Implementações preferidas entre várias que funcionariam.
• Decisões substituídas, para que uma decisão antiga deixe de ser tratada como vigente.

Tudo isso vive em três tipos de conteúdo que a sua equipe pode ler e editar: memórias, regras e skills.

Escopo

A Workspace Intelligence é vinculada a um repositório e, dentro dele, a caminhos.

É esse mecanismo que impede uma camada de conhecimento de virar o próprio problema que deveria resolver. Nem tudo o que vale para um monorepo é relevante para uma mudança em um único pacote, e entregar tudo faz as três frases que importam competirem com duzentas que não importam. O conhecimento fica ligado ao caminho que ele rege, e uma tarefa nesse caminho recebe o que se aplica a ela.

O vínculo com caminhos também é o motivo pelo qual um espaço de trabalho pode continuar crescendo sem que cada turno fique mais pesado. Veja como a recuperação funciona.

Autoridade

A Workspace Intelligence é a camada capaz de guardar requisitos obrigatórios.

Os requisitos vivem nas regras. Uma regra declara o que deve ou não deve acontecer em um escopo, tem uma prioridade e chega em uma seção própria, separada dos conselhos. Uma regra também pode trazer uma restrição executável, um padrão que uma mudança não pode conter. Uma restrição proposta por um agente é armazenada como proposta e não é aplicada; depois que uma pessoa a aprova, o hook pré-ferramenta pode bloquear uma edição correspondente nos clientes cujos hooks dão suporte a isso. Veja regras como guardrails.

Essas são propriedades do projeto. Elas não são deixadas de lado porque uma preferência pessoal seria mais conveniente, e a User Intelligence não pode se sobrepor a elas. Todo o resto que a Workspace Intelligence guarda é consultivo e entregue como conselho, então uma correção anterior nunca é apresentada como se tivesse mais peso que uma regra.

Fontes

São quatro tipos, e faz diferença saber qual é qual.

Escritas. Memórias, regras e skills que uma pessoa escreveu de propósito, ou que um agente escreveu pelas ferramentas do Pathrule, normalmente depois de propor a você. São essas que a equipe pode apontar e discutir, e elas formam a espinha dorsal.

Descobertas a partir do código. Conclusões a que um agente chegou lendo o seu código, salvas junto com os arquivos em que se baseiam e entregues como conselho apenas enquanto esses arquivos não mudarem. Veja aprendizado do projeto.

Evidências do trabalho real. O que as sessões de agentes relataram sobre si mesmas: qual conhecimento foi entregue, qual foi de fato consultado, quais arquivos mudaram juntos, onde um agente continuava travando. Veja o que o Pathrule calcula.

Semeadas a partir do seu checkout, em um espaço de trabalho no Cloud. Na primeira vez que um agente pede contexto aprofundado ao Pathrule em um espaço de trabalho no Cloud, o runtime local lê os caminhos de arquivos do histórico recente do git para descobrir quais arquivos mudaram juntos, e lista os nomes de arquivos nos níveis superiores da árvore de pastas para reconhecer as tecnologias em uso, como uma configuração de TypeScript, Docker ou GitHub Actions. Os pares de caminhos são salvos no espaço de trabalho como ponto de partida de arquivos que mudam juntos, para que o sinal já seja útil antes de a sua equipe ter registrado muito trabalho. Cada tecnologia reconhecida vira uma memória curta na raiz do espaço de trabalho, como "TypeScript project", escrita sem pedir confirmação; é uma memória comum, que você pode editar ou excluir. Um espaço de trabalho local pula essa etapa e aprende quais arquivos mudam juntos apenas a partir do trabalho registrado.

O que não é fonte: o seu código-fonte. O Pathrule não envia o seu código automaticamente, e a semeadura acima lê nomes e caminhos de arquivos, não o conteúdo dos arquivos, diffs nem mensagens de commit. Em um espaço de trabalho no Cloud, o pathrule snapshot, quando você ou o seu agente o executam, envia a árvore de arquivos, os manifestos, pequenos trechos da documentação e metadados recentes do git para que o Pathrule possa descrever o projeto. O que o Pathrule calcula lista o que é lido e o que é guardado.

Team Intelligence

No Pathrule Cloud, a Team Intelligence analisa as evidências que o trabalho de uma equipe produz e propõe padrões: convenções, correções e decisões que aparecem repetidamente. Ela está disponível nos planos Team e Enterprise, e os proprietários e administradores da organização a gerenciam no console web, nas configurações Team guidance da organização.

Um padrão passa de rascunho a sugerido, e uma pessoa o verifica ou o rejeita; uma sugestão sobre a qual ninguém age expira. Só os padrões verificados chegam aos agentes. Nada do que a Team Intelligence infere é considerado confiável por si só.

Ciclo de vida

1. Escrito ou proposto. Uma pessoa escreve com o CLI, a extensão do VS Code ou o próprio agente. Um agente que descobriu algo que vale guardar salva pelas ferramentas de escrita do Pathrule, normalmente depois de propor a você, e a escrita fica atribuída, versionada e reversível. Pedir ao seu agente "Set up Pathrule for this project" dispara uma varredura guiada em que o agente propõe memórias, regras e skills e escreve as que você aprovar. Em um espaço de trabalho no Cloud, o Pathrule também adiciona as memórias curtas de tecnologia descritas acima.
2. Aprovado, quando algo foi inferido. Conhecimento inferido aguarda uma pessoa: a restrição executável de uma regra só é aplicada depois da aprovação, e um padrão da Team Intelligence só chega aos agentes depois de verificado. As descobertas dos agentes são a única exceção, e continuam sendo consultivas. Veja Proposed Knowledge.
3. Entregue. A parte relevante para uma tarefa chega ao agente pelo mecanismo que o cliente dele suporta. Veja Agent IR.
4. Medido. A entrega e o que o agente fez com ela ficam registrados, então o peso de uma entrada reflete o que aconteceu, e não quem a escreveu.
5. Atualizado, substituído ou aposentado. Um conhecimento que parece desatualizado pode ser sinalizado como tarefa de atualização, e uma pessoa ou um agente cuida dela. Uma decisão que foi substituída por outra posterior deixa de ser tratada como vigente. Veja sugestões e autoauditoria.

O que muda quando você troca de projeto

Tudo. A Workspace Intelligence pertence ao repositório, e abrir outro repositório significa outro conjunto de conhecimento do projeto, compartilhado com quem mais trabalha nele.

O que vai com você é a User Intelligence, que pertence a você: as preferências que você ensinou ao Pathrule e escolheu aplicar em todo lugar.