Grove

O código cresce. As janelas de contexto não. Plante um Grove 🌳

Graph-driven Reasoning Over Verified Evidence. Um protocolo de fluxo de trabalho formal, projetado para manter projetos profundos e de longa duração coerentes entre sessões, agentes e meses.

O trabalho de agentes de longa duração falha de uma forma previsível: decisões e suposições saem de vista conforme as sessões crescem, agentes relatam trabalho concluído que não está concluído e, após alguns meses, o código-fonte não corresponde mais ao que qualquer um acredita sobre ele, então ninguém consegue dizer por que uma determinada linha existe.

O Grove se encaixa em trabalhos com forte carga de raciocínio que sobrevivem a uma única sessão: refatorações longas, funcionalidades de múltiplas sessões, trabalhos de segurança e conformidade em que cada conclusão precisa de uma trilha de auditoria. O protocolo escolhe o próximo passo, para que você pare de reexplicar o projeto a cada nova sessão.

O que isso oferece:

• Progresso atômico: cada tarefa é comprovada mecanicamente, não apenas declarada.
• Hierarquia em vez de compressão: o contexto é estritamente estruturado, nunca resumido com perdas.
• Reprodutibilidade absoluta: cada ação é registrada, para que qualquer passo, decisão ou suposição possa ser reproduzido e rastreado.
• Continuidade entre agentes: se um agente parar no meio de um objetivo, outro agente em outro cliente ou modelo retoma a partir do estado verificado.
• Propriedade total: cada objetivo, decisão, tarefa, pergunta e suposição é armazenado em um grafo histórico persistente que pertence inteiramente a você.

O Grove impõe suas regras como invariantes determinísticas armazenadas em um único arquivo de bloqueio com soma de verificação: o agente não pode declarar trabalho concluído sem evidências falseáveis, iniciar tarefas não prontas ou alucinar progresso. Em vez de compressão de prompt ou sumarização com perdas, o estado do projeto vive em um grafo de raciocínio tipado com arestas verificáveis por máquina, e cada passo recebe exatamente o pacote de execução de que precisa, e nada mais.

Funciona com Claude Code, Codex, Gemini CLI, Cursor, Windsurf, Cline, GitHub Copilot e qualquer outro agente. O Grove inclui uma CLI, um servidor MCP integrado e um pacote de habilidades de agente pronto para uso para que você possa integrá-lo ao seu espaço de trabalho imediatamente.

[!IMPORTANT] Uma nota sobre o aplicativo de desktop mostrado abaixo. Ele existe para tornar o grafo, as evidências e a saúde de um projeto visíveis de relance, mas ainda é experimental e não foi testado no macOS ainda. A CLI e o servidor MCP são as interfaces estáveis e testadas. A interface do usuário é implementada sem nenhum framework JavaScript, principalmente HTML puro, CSS e Tauri, o que a mantém rápida, e o grafo é renderizado com WebGL.

O grafo de raciocínio, explorado ao vivo.	A mesma visão com 143 nós, histórico incluído.	Tudo o que um agente precisa para um item de trabalho, nada mais.
Itens de trabalho rastreados da proposta à conclusão.	Objetivos, trabalho e saúde do conteúdo por área.	Trabalho agrupado por tema, com o caminho crítico.

Agentes perdem contexto conforme os projetos crescem

Agentes de longa duração sofrem de amnésia de contexto. Decisões, suposições e dependências saem de vista conforme a sessão cresce. Uma falha relacionada é o autorrelato não confiável: o agente declara trabalho concluído sem evidências suficientes. Isso acontece não por engano, mas porque nada no ambiente impede isso.

Rastreadores de tarefas padrão confiam inerentemente no executor. Quando um humano marca uma caixa no Jira, presume-se que o trabalho está concluído. Esse é um padrão razoável para humanos. Para agentes autônomos, é um modo de falha silencioso. Declarações prematuras de "concluído" se acumulam em sessões longas até se tornarem erros estruturais, até que o código-fonte não corresponda mais ao que qualquer um acredita que ele seja, e ninguém consiga dizer por que uma determinada linha existe.

Isso não é teórico. O Grove evoluiu de uma hipótese rudimentar em Markdown para um protocolo que hoje gerencia o Merlin Guild, um projeto de produção de código fechado com mais de 200 mil linhas de Rust e TypeScript, com forte foco em blockchain e criptografia. Ele escala porque o protocolo não depende de o agente lembrar ou obedecer corretamente ao fluxo de trabalho.

Estrutura em vez de compressão

A resposta óbvia à amnésia de contexto é mais ferramentas: sumarização, compactação, recuperação. Todas elas comprimem o contexto, e a compressão perde informações enquanto espera que a perda não importe.

O Grove não comprime contexto. Ele o estrutura.

Conforme um projeto evolui, seu trabalho é continuamente organizado em áreas, objetivos, perguntas, suposições, decisões e itens de trabalho executáveis. Essa hierarquia dá ao agente uma maneira de identificar o contexto relevante para o passo atual, em vez de carregar repetidamente todo o histórico do projeto para sua janela de contexto.

O resultado não é apenas melhor continuidade; também reduz o uso de tokens. O agente não carrega mais contexto não relacionado do projeto apenas para recuperar onde está e por que a tarefa atual existe.

Mapeie todo o código-fonte em um único prompt

O que acontece quando você aponta um modelo de fronteira para um código-fonte bruto com o Grove anexado?

Sem um protocolo, um agente folheia os arquivos, alucina um resumo rápido e perde o fio da meada após alguns passos. Com o Grove, ele mapeia o território. Em um teste no mundo real em um código-fonte complexo, um único prompt iniciou uma sessão autônoma de Discovery de 5 horas.

O agente estourou o limite da janela de contexto, mas o resultado foi um grafo de raciocínio totalmente preenchido: 44 Áreas, 47 Objetivos e 89 Itens de trabalho visando lacunas de cobertura de testes e bugs de lógica. Ele não apenas despejou uma lista de tarefas plana; declarou formalmente suas incógnitas abertas como Perguntas e agrupou esforços relacionados em Temas.

Aqui está o prompt exato usado para inicializar o projeto:

Carregue a habilidade do Grove e conecte-se ao servidor MCP. Estude a habilidade completamente para entender as restrições do protocolo.

Seu objetivo é executar uma fase completa de Discovery em todo o código-fonte. Não escreva código de implementação ainda; seu trabalho é análise de projeto e construção do grafo.

1. Divida o projeto em Áreas. Observe que um único pacote pode conter múltiplas áreas lógicas.
2. Itere por cada Área e crie Objetivos para abordar lacunas de cobertura de testes e bugs de lógica explícitos.
3. Para cada Objetivo, crie Itens de trabalho estritamente formatados de acordo com o protocolo do Grove.
4. Agrupe trabalhos relacionados em Temas.
5. Declare incógnitas abertas como Perguntas e formalize escolhas arquiteturais como Decisões quando necessário.

Como o Grove impõe uma Definição de Pronto (DoR), o agente não pôde fingir progresso. No dia seguinte, o agente executou sistematicamente a fase de entrega, transformando 75 tarefas em Concluídas. As tarefas restantes pararam corretamente nos estados proposed ou ready, aguardando respostas humanas para as Perguntas bloqueadoras que o agente havia levantado.

Um estado de projeto, múltiplas interfaces

A unidade de memória não é a conversa. É o projeto.
A unidade de progresso não é a declaração do agente. É a evidência verificada.

O Grove substitui instruções educadas de prompt por um protocolo estrito e mecanicamente imposto. Os agentes interagem com o estado do projeto por meio da CLI, do MCP e das interfaces de desktop. O próprio protocolo impõe as regras:

• Um item de trabalho não pode ser marcado como concluído sem um registro de evidência.
• O trabalho não pode começar até que cada pré-condição seja verificada por máquina.
• O progresso do objetivo não pode ser atualizado manualmente; os deltas de aptidão são aplicados atomicamente no momento do fechamento ou não são aplicados.

O estado ou satisfaz o protocolo, ou o Grove se recusa a avançá-lo. Um agente não pode avançar o estado do protocolo meramente declarando que o trabalho está concluído.

Dê aos agentes apenas o contexto de que precisam

O Grove força o agente a decompor o produto em uma hierarquia tipada estrita. Em vez de uma lista bruta de tarefas, cada peça de contexto de planejamento vive explicitamente em uma taxonomia de nós. Nada fica escondido em documentos paralelos ou no estado interno do agente:

Nó	ID	O que contém
Área	A-NN	Esqueleto de escopo permanente acima dos objetivos; nunca arquivado.
Objetivo	G-NN	Resultado com uma função de aptidão mensurável.
Tema	T-NN	Agrupamento opcional de itens de trabalho relacionados.
Trabalho	W-NN	Unidade executável com Definição de Pronto + Definição de Concluído.
Decisão	D-NN	ADR: imutável uma vez aceita, substituída apenas com justificativa registrada.
Pergunta	Q-NN	Incógnita aberta, declarada em vez de fingida como resolvida.
Suposição	B-NN	Hipótese falseável com método de validação e resultado.
Descoberta	Y-NN	Conhecimento reutilizável e baseado em evidências, destilado de trabalho concluído.

Arestas tipadas conectam esses nós em um grafo, com blocos permanecendo acíclicos. Essa estrutura permite que o Grove responda tanto a por que essa tarefa existe? quanto a o que quebra se eu mudá-la? sem depender do estado interno do agente.

Uma vez que esse grafo existe, o roteamento prometido acima se torna mecânico. grove next escolhe o passo atual; grove packet emite exatamente seu contexto. Nada irrelevante entra na janela de contexto.

Antes de tocar em uma linha de código, o agente consulta o cone de causalidade. grove packet W-NN --cone mapeia o cone reverso (tudo o que deve terminar primeiro, em ordem de contração topológica), o cone direto (o raio de explosão se este item mudar) e uma pontuação de fragilidade por objetivo afetado.

Transforme raciocínio em conhecimento reutilizável

Grove introduz uma metodologia unificada para desenvolvimento de software orientado por IA, fundamentada em Dual-Track Agile, Desenvolvimento Orientado por Hipóteses, ADRs, Descoberta Contínua, Cynefin e o método Mikado. Essas influências são integradas em um único fluxo de trabalho projetado em torno das restrições de agentes LLM autônomos e aplicadas por meio de invariantes verificáveis por máquina.

A maioria dos fluxos de trabalho de IA são minicascatas: especifique tudo, depois construa tudo. O Grove executa descoberta e entrega em paralelo, cada trilha alimentando a outra:

• Descoberta pega incógnitas em aberto e as operacionaliza. Uma pergunta se torna uma suposição falseável; resultados validados se tornam descobertas curadas.
• Entrega executa itens de trabalho prontos e escreve código verificado com base nessas suposições.

As articulações são mecânicas. Perguntas são feitas em relação às metas; suposições direcionam o trabalho e o controlam; descobertas orientam as próximas metas; o trabalho concluído se destila de volta em descobertas. Quando um teste falseia uma suposição, o plano se remodela imediatamente; o trabalho dependente não pode prosseguir sobre uma base quebrada.

O conhecimento tem um ciclo de vida

O Grove não trata o conhecimento destilado como verdade permanente. Descobertas podem se tornar obsoletas à medida que o projeto evolui; reativar uma delas exige uma nova âncora. A dívida de destilação é rastreada em vez de se acumular silenciosamente, enquanto a adequação das metas é recalculada a cada fechamento.

O painel reflete o estado real do protocolo após cada mutação, não o estado pretendido. O Grove assume que um projeto continua em movimento: o conhecimento muda, suposições são invalidadas e raciocínios inacabados se acumulam. O protocolo torna essas mudanças visíveis em vez de deixá-las desaparecer no histórico do projeto.

Ideias por trás do protocolo

• Descoberta e Entrega rodam em paralelo (Dual-Track Agile, Cagan). Um item de trabalho não pode entrar em Entrega até que toda pergunta em aberto e suposição não validada que o bloqueie seja resolvida na Descoberta.
• Cada unidade executável tem critérios de aceitação explícitos antes de o código ser escrito (HDD, Definition of Ready). O DoR não é uma lista de verificação que qualquer um possa substituir; é uma conjunção booleana que a CLI avalia em cada transição status=progress.
• Escolhas de design de longa duração são artefatos de primeira classe (ADR, Nygard). Decisões são imutáveis uma vez aceitas. Elas não podem ser silenciosamente revisadas; só podem ser substituídas por uma nova decisão com uma justificativa registrada.
• Incógnitas em aberto são artefatos de primeira classe; agentes as declaram em vez de fingir que sabem (Descoberta Contínua; Cynefin). Uma pergunta marcada com chaotic interrompe o agente e exige resolução humana.
• Suposições são portões falseáveis, não comentários. Uma suposição no estado invalidated_blocking impede que qualquer item de trabalho dependente fique pronto. O agente não pode prosseguir ignorando-a.
• Refatoração usa um grafo de dependências estilo Mikado que distingue causalidade, sequenciamento, implementação e investigação. Isso torna o raio de impacto de uma mudança explícito antes que a primeira linha seja tocada.
• Metas verificadas são arquivadas somente após a destilação: suas suposições validadas, perguntas respondidas e decisões aceitas se tornam Descobertas (Y), axiomas de domínio curados que nunca são arquivados e que alimentam pacotes futuros.
• Áreas (A) são um esqueleto de escopo permanente acima das metas. Toda meta pertence a exatamente uma área, aplicado pela CLI na criação (I₁₃); áreas nunca são arquivadas, então a estrutura sobrevive a qualquer meta individual.

Além do desenvolvimento orientado por especificação

O desenvolvimento orientado por especificação torna as especificações explícitas. O Grove vai um passo além: torna o próprio processo de desenvolvimento executável e verificável.

Uma especificação descreve o que o sistema deve fazer. O Grove também modela o estado do trabalho ao redor dele: o que é comprovado, o que é assumido, o que está bloqueado, o que está pronto, o que está concluído e com base em quais evidências. Esses não são instruções para o agente seguir; são estados do protocolo que controlam o que o agente pode fazer em seguida.

Isso muda o fluxo de trabalho de execução orientada por documentos para execução orientada por estado. Não há uma única especificação para regenerar o projeto e nenhuma cascata fixa por recurso. Descoberta e entrega rodam continuamente, e quando uma suposição é falseada, o grafo e o plano de execução mudam com ela. Cada transição de estado é mecanicamente controlada em vez de depender de o agente seguir o processo corretamente.

As especificações continuam úteis. No Grove, elas podem viver como decisões, critérios de aceitação e outros conhecimentos estruturados do projeto anexados ao trabalho. O que muda é o que as aplica: a especificação descreve o resultado pretendido; o protocolo determina se o projeto pode avançar.

Deixe a evidência decidir quando o trabalho está concluído

Uma tarefa nem sequer pode começar até que uma Definition of Ready passe. Esta é uma conjunção booleana estrita avaliada pelo protocolo em toda transição status=progress, não uma lista de verificação que qualquer um possa substituir. Uma vez pronto, o Grove emite um pacote de execução: exatamente o contexto que a etapa precisa (o item de trabalho, seus critérios de aceitação, suas perguntas em aberto, sua cadeia de suposições e as decisões que o restringem) e nada mais.

O fechamento exige evidências falseáveis: saídas de teste, hashes de commit, logs de build. Um finished autorrelatado não é aceito. A transição para done é atômica; os deltas de adequação da meta e a re-derivação de status são aplicados na mesma escrita, ou não são aplicados.

Raciocínio versionado, não apenas código versionado

Todo o estado vive em .grove/state.lock, um único arquivo de texto orientado a linhas com uma soma de verificação SHA-256 reescrita a cada mutação. Qualquer edição manual, script desonesto ou merge ruim é detectado na próxima operação do protocolo, e todas as transições de estado são bloqueadas até que o arquivo seja reparado.

O lockfile pode viver dentro do repositório do projeto, para que o histórico do raciocínio do projeto evolua junto com o código, ou fora dele em um diretório ou repositório separado. Ambas as topologias são suportadas. Quando commitado no controle de versão, o histórico do lockfile se torna o histórico do raciocínio do projeto, não apenas do seu código.

Conflitos de merge e condições de corrida

Uma corrida típica ocorre quando dois branches avançam o estado do projeto de forma independente:

1. O branch A é mesclado em main e avança o estado do projeto.
2. O branch B foi criado antes e ainda contém a soma de verificação do estado anterior.
3. Mesclar os branches produz uma incompatibilidade de soma de verificação.

O Grove detecta a divergência em vez de aceitar silenciosamente um estado inconsistente.

A resolução é mecânica:

1. Resolva os conflitos textuais, mantendo registros de ambos os lados.
2. Execute grove repair --confirm para re-canonicalizar e recalcular a soma de verificação do estado.
3. Execute grove check para revelar quaisquer violações de invariantes.
4. Execute grove renumber se ocorrerem colisões de ID entre branches.

Trabalho paralelo

Para worktrees paralelos, grove init --id-stride/--id-offset aloca faixas de ID disjuntas para que colisões não aconteçam em primeiro lugar.

Em uma única máquina, mutações concorrentes são protegidas por um flock exclusivo, enquanto o trabalho reivindicado é protegido por tokens de sessão.

Escritas multi-máquina em um único lockfile estão fora do escopo por design. Transições de estado remoto devem ser roteadas por um único escritor canônico, como um agente de CI primário.

Histórico executável, não apenas uma trilha de auditoria

O Git versiona código. O Grove versiona o raciocínio que o produziu. A maioria dos harnesses de agentes e ferramentas SDD (Desenvolvimento Orientado por Especificação) perdem o "porquê" no momento em que uma tarefa é fechada. O Grove registra cada ação em um diário executável e persistente, dando a você algo sem precedentes: um desfazer e repetir completos no nível das decisões do projeto.

Cada mutação acrescenta uma linha JSON a .grove/journal.log contendo o comando, o timestamp UTC, o token de sessão que a escreveu e o inverso exato da mudança.

{"v":1,"ts":"2026-07-19T12:35:19Z","cmd":"set","inv":{"op":"set_status_plain","id":"B-01","old_status":"testing"},"session":"host:0123456789abcdef"}

Como cada registro carrega seu próprio inverso, o diário é executável. grove undo reproduz esses inversos em ordem reversa, restaurando o estado anterior exato até os status das metas, deltas de adequação e reivindicações de sessão. O Git reverte a implementação; o Grove reverte a hipótese, o status da suposição e a adequação da meta que a justificaram.

Isso desbloqueia a verdadeira reprodução do projeto. Você pode pegar o estado em t=0 e reproduzir o diário para ver exatamente como o projeto chegou à sua forma atual. Ele atua como um git blame para decisões: em vez de apenas ver quem escreveu uma linha de código, você reconstrói qual suposição foi validada, qual evidência forçou uma mudança de direção e por que um caminho específico foi escolhido.

O diário também captura o trabalho invisível do agente. Quando a guarda da Definition of Ready (DoR) rejeita uma transição, o diário registra os conjuntos exatos que falharam. Registros de auditoria, como execuções de portão, rejeições e desfazimentos, nunca são invertidos e nunca são truncados. Isso captura o que o agente tentou, não apenas o que ele mudou.

Essa trilha persistente alimenta grove log e grove stats: reconstruindo tempos de ciclo, taxas de primeira passagem no DoR e saúde do conteúdo em qualquer ponto da história. Como é escrito em linhas JSON simples, não requer permissões especiais para leitura, servindo como matéria-prima para construir suas próprias métricas ou conduzir análises post-mortem de padrões de falha de agentes.

Continue quando o agente desaparecer

Um item de trabalho em andamento carrega um token de sessão exclusivo (somente a sessão que o reivindicou pode mutá-lo). Se um provedor cair no meio de uma meta, ou uma refatoração difícil exigir um modelo diferente, outro agente em outro cliente assume via grove handoff. Alternativamente, ele adota a sessão via grove resume.

Todo o raciocínio e a prova vivem no lockfile, então grove next e grove packet reconstroem o contexto de trabalho instantaneamente. Os invariantes mantêm o novo agente honesto; o resto do progresso não pode ser falsificado.

O verdadeiro teste do desenvolvimento orientado por agentes é exatamente este: quando o agente para no meio de uma meta, o próximo retoma o projeto sem reconstruir a intenção a partir de logs de chat.

Preserve o porquê do trabalho existir

O resultado não é apenas continuidade para agentes. É explicabilidade para as pessoas que possuem o projeto.

Você pode responder por que um pedaço de código existe, do que ele depende, em quais suposições se apoia e qual evidência o justificou meses após o trabalho original ter sido concluído.

Começando

O Grove é projetado para ser instalado uma vez e depois usado como a camada de fluxo de trabalho persistente do seu projeto.

O guia de instalação cobre a CLI, o servidor MCP, o aplicativo desktop e o pacote de habilidades do agente. Em seguida, execute grove init na raiz do seu projeto para criar o arquivo de estado com soma de verificação. Conecte o servidor MCP, adicione a habilidade assinada e inicialize sua primeira sessão com um modelo de prompt. A partir daí, grove next conduz cada sessão.

Não tem certeza se o Grove se encaixa no seu fluxo de trabalho? O Gemini Notebook contém a documentação completa. Comece com uma pergunta simples, como "Como o Grove impede um agente de marcar trabalho como concluído sem evidência?" ou "Quando o Grove é a ferramenta errada para o meu projeto?"

Onde ele se encaixa

O Grove é mais útil quando o trabalho é de longa duração, pesado em raciocínio e executado por agentes autônomos.

Fluxos de trabalho de segurança e pesquisa: o trabalho de segurança se estende por meses e roda sobre hipóteses: a maioria das pistas morre, algumas se tornam caminhos críticos. O Grove se encaixa nesse formato nativamente. Cada item fechado carrega evidência, então a trilha de auditoria é o próprio projeto - o diário somente de acréscimos, decisões imutáveis e fechamentos vinculados a evidências respondem "quem concluiu o quê, quando e com base em quê" sem um processo de relatório separado. As prioridades deixam de ser um sentimento: o caminho crítico, a adequação por meta e os portões DoR decidem o que roda em seguida, formalmente. Trabalho de arquitetura e conformidade: as suposições no Grove carregam um método de validação e um resultado; as decisões carregam a justificativa; as descobertas ancoram invariantes a superfícies concretas. "Ainda estamos cumprindo nossos SLOs" torna-se uma pergunta que o estado responde por meio de métricas de adequação de metas, e "por que foi construído assim" permanece respondível meses depois - cada escolha arquitetural aponta para as perguntas, suposições e evidências que a produziram.

Refatorações longas e recursos de múltiplas sessões: o grafo de dependências no estilo Mikado e o cone de causalidade tornam o raio de impacto explícito antes da primeira edição, e a continuidade de sessão permite que o trabalho sobreviva a mudanças de agente e provedor.

O Grove geralmente é a ferramenta errada para protótipos de curta duração, tarefas de um único prompt e projetos em que o código não sobreviverá à sessão.

O Grove não é um gerenciador de tarefas, ferramenta de contexto de código ou orquestrador multiagente. É um protocolo para manter estado de projeto verificado para agentes autônomos.

Invariantes do protocolo

I₁:  ∀ w ∈ W with status = progress, DoR(w) ≡ ⊤.
I₂:  ∀ w with type = spike ∧ status = done,
      produces(w) ⊆ D ∪ Q ∪ B ∪ Y  ∧  produces(w) ≠ ∅.
I₃:  ∀ w with status = done, ∃ ev ∈ Evidence, satisfies(ev, AC(w)).
I₄:  |{ w ∈ W : status(w) = progress }| ≤ WIP_LIMIT (default 2).
I₅:  ∀ (n₁, blocks, n₂) ∈ E, terminal⁺(n₁) before status(n₂) may transition to progress.
I₆:  ∀ t ∈ T, status(t) = done ⟺ ∀ w ∈ WI(t), status(w) ∈ { done, rejected, archived }.
I₇:  graph (N, E ∩ (· × {blocks} × ·)) is a DAG.
I₈:  ∀ q ∈ Q with cynefin(q) = chaotic, status transitions only via human.
I₉:  ∀ w ∈ W with type = feature, DoR(w) ⇒
      ∀ b ∈ BChain(w), status(b) ∈ { validated, invalidated_acceptable }.
I₁₀: status transition w → done is atomic with applying fitness deltas
      to each g ∈ goals(w) and re-deriving status(g). Either both succeed or
      neither does. The CLI rejects status=done unless deltas are staged
      in the same call (or pre-staged via `grove fitness` since the last
      status mutation of w).
I₁₁: ∀ w ∈ W with status = progress, the session that set it is the only
      session permitted to mutate w until terminal(w) or w leaves `progress`
      (e.g. `revert` or another guarded status change). Persisted as header
      attrs `session` and `session_at` (UTC); `check` rejects a missing token
      (`grove resume` adopts; see protocol §2.6).
I₁₂: ∀ y ∈ Y: (≥1 provenance edge: (w, produces, y) ∨ (y, distills, d/q/b))
      ∧ (surface(y) ≠ ∅ ∨ why(y) ≠ ∅) ∧ tags(y) ≠ ∅ (≥1 glossary term).
      `proposed → active` is refused while any conjunct fails; `stale → active`
      only via `grove revalidate` paid with a fresh anchor.
I₁₃: ∀ g ∈ G: ∃ a ∈ A with area(g) = a.id, recorded as the mandatory `area`
      field and enforced at creation (`grove add g --area=A-NN`); re-partition
      via `grove set G-NN area=A-NN`. An area-less goal in the lock is a
      violation, never silently repaired.

com terminalidade:

terminal(w ∈ W)  ⟺ status(w) ∈ { done, rejected, archived }
terminal⁺(g ∈ G) ⟺ status(g) = verified (strict for blocks edges)
terminal(g ∈ G)  ⟺ status(g) ∈ { verified, declined }
terminal(d ∈ D)  ⟺ status(d) ∈ { accepted, rejected, superseded }
terminal(q ∈ Q)  ⟺ status(q) ∈ { answered, deferred, dropped }
terminal(b ∈ B)  ⟺ status(b) ∈ { validated, invalidated_acceptable, invalidated_blocking }
terminal(t ∈ T)  ⟺ status(t) = done
terminal(y ∈ Y)  ⟺ status(y) = superseded
terminal(a ∈ A)  ⟺ ⊥ (areas have no lifecycle)

terminal⁺ é a variante estrita usada para arestas blocks: uma meta declined não desbloqueia dependentes. Outras relações usam o terminal flexível.

assumptions(w) ≜ { b ∈ B | (b, targets, w) ∈ E }
BChain(w)      ≜ assumptions(w) ∪ { b ∈ B | ∃ q, (q, asks, w) ∈ E ∧ (b, tests, q) ∈ E }
produces(w)    ≜ { n ∈ D ∪ Q ∪ B ∪ Y | (w, produces, n) ∈ E }
goals(w)       ≜ as recorded in `goals` field of w
WI(t)          ≜ { w ∈ W | theme(w) = t }

FAQ

Como funciona o arquivo de estado?

Todo o estado reside em .grove/state.lock, um único arquivo de texto orientado a linhas com uma soma de verificação SHA-256 em cada gravação. Qualquer edição manual é detectada imediatamente na próxima operação do protocolo, e todas as transições de estado são bloqueadas até que o arquivo seja reparado. O agente nunca lê ou grava o arquivo diretamente; ele interage apenas por meio das interfaces do Grove (CLI, MCP).

Esse design torna todo o fluxo de trabalho auditável e amigável a diffs. Cada transição é uma única gravação atômica. O arquivo de bloqueio pode ser commitado no controle de versão; seu histórico é o histórico do raciocínio do projeto, não apenas do seu código.

Como um agente trabalha com o Grove de forma eficiente? Ele precisa ler toda a habilidade e escrever redações no bloqueio?

Não em ambos os casos. O index.md da habilidade é o contrato mínimo seguro - uma tela, completa para operação; todas as outras páginas são profundidade que você abre apenas quando a tarefa toca no tópico. E quando a forma de um comando não está clara, o próprio CLI é o instrutor: recusas como add g: --area is required ou DoR ≢ ⊤; see grove dor W-NN dizem exatamente o que está faltando. Mesmo um agente que nunca abriu a habilidade não pode corromper o estado, porque os invariantes (portões DoR, portões de evidência, a soma de verificação) são aplicados pelo protocolo, não pelo documento - a leitura parcial degrada a qualidade do processo, nunca a integridade.

Escrever funciona por compressão, não por transcrição. O agente delibera em seu próprio contexto pelo tempo que precisar e, em seguida, armazena apenas as conclusões: um critério de aceitação por linha, uma frase por hipótese, um bloco compacto de contexto/opções em um nó de decisão. Dezenas de pequenas chamadas de CLI são normais e baratas - elas são agrupadas em uma única invocação de shell por nó (add + campos + fitness). O que nunca pertence ao bloqueio é o próprio raciocínio: se um fato não muda o que um agente futuro faz, ele não é registrado. E grove next / grove packet existem precisamente para que o agente nunca releia o arquivo de estado para planejar.

Licença

GNU Affero General Public License v3.0 (AGPL-3.0). Copyright (c) 2026 Alex Shelepenok. Livre para usar, estudar, modificar e redistribuir sob os termos da licença, incluindo uso em rede: oferecer o Grove como um serviço de rede exige oferecer seu código-fonte. Consulte LICENSE para o texto completo.