Grove

El código crece. Las ventanas de contexto no. Planta un Grove 🌳

Graph-driven Reasoning Over Verified Evidence. Un protocolo de trabajo formal diseñado para mantener proyectos profundos y de larga duración coherentes entre sesiones, agentes y meses.

El trabajo de agentes de larga duración falla de una manera predecible: las decisiones y suposiciones se pierden de vista a medida que las sesiones crecen, los agentes reportan trabajo completado que no está completado, y después de unos meses el código base ya no coincide con lo que cualquiera cree sobre él, así que nadie puede decir por qué existe una línea determinada.

Grove se adapta a trabajos intensivos en razonamiento que sobreviven a una sola sesión: refactorizaciones largas, funciones de múltiples sesiones, trabajo de seguridad y cumplimiento donde cada conclusión necesita un rastro de auditoría. El protocolo elige el siguiente paso, para que dejes de reexplicar el proyecto a cada nueva sesión.

Lo que esto te ofrece:

• Progreso atómico: cada tarea se prueba mecánicamente, no solo se afirma.
• Jerarquía sobre compresión: el contexto está estrictamente estructurado, nunca resumido con pérdida de información.
• Reproducibilidad absoluta: cada acción se registra, por lo que cualquier paso, decisión o suposición puede reproducirse y rastrearse.
• Continuidad entre agentes: si un agente se detiene a mitad de un objetivo, otro agente en otro cliente o modelo se reanuda desde el estado verificado.
• Propiedad total: cada objetivo, decisión, tarea, pregunta y suposición se almacena en un grafo histórico persistente que te pertenece por completo.

Grove aplica sus reglas como invariantes deterministas almacenadas en un único archivo de bloqueo con suma de verificación: el agente no puede declarar trabajo completado sin evidencia falsable, iniciar tareas no preparadas o alucinar progreso. En lugar de compresión de prompts o resúmenes con pérdida, el estado del proyecto vive en un grafo de razonamiento tipado con aristas verificables por máquina, y cada paso recibe exactamente el paquete de ejecución que necesita, y nada más.

Funciona con Claude Code, Codex, Gemini CLI, Cursor, Windsurf, Cline, GitHub Copilot y cualquier otro agente. Grove incluye una CLI, un servidor MCP integrado y un paquete de habilidades de agente listo para usar para que puedas integrarlo en tu espacio de trabajo de inmediato.

[!IMPORTANT] Una nota sobre la aplicación de escritorio que se muestra a continuación. Existe para hacer visible el grafo, la evidencia y la salud de un proyecto de un vistazo, pero aún es experimental y no se ha probado en macOS todavía. La CLI y el servidor MCP son las interfaces estables y probadas. La interfaz de usuario está implementada sin ningún framework de JavaScript, principalmente HTML plano, CSS y Tauri, lo que la mantiene rápida, y el grafo se renderiza con WebGL.

El grafo de razonamiento, explorado en vivo.	La misma vista con 143 nodos, historial incluido.	Todo lo que un agente necesita para un elemento de trabajo, nada más.
Elementos de trabajo rastreados desde la propuesta hasta su finalización.	Objetivos, trabajo y salud del contenido por área.	Trabajo agrupado por tema, con la ruta crítica.

Los agentes pierden contexto a medida que los proyectos crecen

Los agentes de larga duración sufren de amnesia de contexto. Las decisiones, suposiciones y dependencias se pierden de vista a medida que la sesión crece. Un fallo relacionado es el auto-reporte poco fiable: el agente declara trabajo completado sin evidencia suficiente. Esto no ocurre por engaño, sino porque nada en el entorno lo impide.

Los rastreadores de tareas estándar confían inherentemente en el ejecutor. Cuando un humano marca una casilla en Jira, se asume que el trabajo está hecho. Ese es un valor predeterminado razonable para humanos. Para agentes autónomos es un modo de fallo silencioso. Las declaraciones prematuras de "hecho" se acumulan en sesiones largas hasta convertirse en errores estructurales, hasta que el código base ya no coincide con lo que cualquiera cree que es, y nadie puede decir por qué existe una línea determinada.

Esto no es teórico. Grove evolucionó de una hipótesis cruda en Markdown a un protocolo que hoy gestiona Merlin Guild, un proyecto de producción de código cerrado con más de 200k líneas de Rust y TypeScript, con mucho trabajo en blockchain y criptografía. Escala porque el protocolo no depende de que el agente recuerde u obedezca el flujo de trabajo correctamente.

Estructura en lugar de compresión

La respuesta obvia a la amnesia de contexto es más herramientas: resúmenes, compactación, recuperación. Todas estas comprimen el contexto, y la compresión pierde información mientras espera que la pérdida no importe.

Grove no comprime el contexto. Lo estructura.

A medida que un proyecto evoluciona, su trabajo se organiza continuamente en áreas, objetivos, preguntas, suposiciones, decisiones y elementos de trabajo ejecutables. Esta jerarquía le da al agente una forma de identificar el contexto relevante para el paso actual en lugar de cargar repetidamente todo el historial del proyecto en su ventana de contexto.

El resultado no es solo una mejor continuidad; también reduce el uso de tokens. El agente ya no carga contexto del proyecto no relacionado simplemente para recuperar dónde está y por qué existe la tarea actual.

Mapea todo el código base en un solo prompt

¿Qué sucede cuando apuntas un modelo de frontera a un código base crudo con Grove adjunto?

Sin un protocolo, un agente hojea los archivos, alucina un resumen rápido y pierde el hilo después de unos pocos pasos. Con Grove, mapea el territorio. En una prueba del mundo real en un código base complejo, un solo prompt inició una sesión autónoma de Discovery de 5 horas.

El agente agotó su límite de ventana de contexto, pero el resultado fue un grafo de razonamiento completamente poblado: 44 Áreas, 47 Objetivos y 89 Elementos de trabajo dirigidos a brechas de cobertura de pruebas y errores lógicos. No solo arrojó una lista plana de tareas pendientes; declaró formalmente sus incógnitas abiertas como Preguntas y agrupó esfuerzos relacionados en Temas.

Aquí está el prompt exacto utilizado para iniciar el proyecto:

Carga la habilidad de Grove y conéctate al servidor MCP. Estudia la habilidad por completo para entender las restricciones del protocolo.

Tu objetivo es ejecutar una fase completa de Discovery en todo el código base. No escribas código de implementación todavía; tu trabajo es el análisis del proyecto y la construcción del grafo.

1. Divide el proyecto en Áreas. Ten en cuenta que un solo paquete puede contener múltiples áreas lógicas.
2. Itera a través de cada Área y crea Objetivos para abordar la cobertura de pruebas faltante y los errores lógicos explícitos.
3. Para cada Objetivo, crea Elementos de trabajo estrictamente formateados según el protocolo de Grove.
4. Agrupa el trabajo relacionado en Temas.
5. Declara las incógnitas abiertas como Preguntas y formaliza las elecciones arquitectónicas como Decisiones cuando sea necesario.

Debido a que Grove aplica una Definición de Preparación (DoR), el agente no pudo fingir progreso. Durante el día siguiente, el agente ejecutó sistemáticamente la fase de entrega, convirtiendo 75 tareas en Hecho. Las tareas restantes se detuvieron correctamente en estados proposed o ready, esperando respuestas humanas a las Preguntas bloqueantes que el agente había planteado.

Un estado de proyecto, múltiples interfaces

La unidad de memoria no es la conversación. Es el proyecto.
La unidad de progreso no es la afirmación del agente. Es evidencia verificada.

Grove reemplaza las instrucciones de prompt corteses con un protocolo estricto y aplicado mecánicamente. Los agentes interactúan con el estado del proyecto a través de la CLI, MCP e interfaces de escritorio. El protocolo mismo aplica las reglas:

• Un elemento de trabajo no puede marcarse como hecho sin un registro de evidencia.
• El trabajo no puede comenzar hasta que cada condición previa esté verificada por máquina.
• El progreso del objetivo no puede actualizarse manualmente; los deltas de aptitud se aplican atómicamente al momento del cierre o no se aplican en absoluto.

El estado o satisface el protocolo, o Grove se niega a avanzarlo. Un agente no puede avanzar el estado del protocolo simplemente afirmando que el trabajo está completo.

Dale a los agentes solo el contexto que necesitan

Grove obliga al agente a descomponer el producto en una jerarquía tipada estricta. En lugar de una lista cruda de tareas, cada pieza de contexto de planificación vive explícitamente en una taxonomía de nodos. Nada se esconde en documentos secundarios o en el estado interno del agente:

Nodo	ID	Qué contiene
Área	A-NN	Esqueleto de alcance permanente por encima de los objetivos; nunca se archiva.
Objetivo	G-NN	Resultado con una función de aptitud medible.
Tema	T-NN	Agrupación opcional de elementos de trabajo relacionados.
Trabajo	W-NN	Unidad ejecutable con Definición de Preparación + Definición de Hecho.
Decisión	D-NN	ADR: inmutable una vez aceptada, superada solo con una justificación registrada.
Pregunta	Q-NN	Incógnita abierta, declarada en lugar de fingir que no existe.
Suposición	B-NN	Hipótesis falsable con un método de validación y resultado.
Descubrimiento	Y-NN	Conocimiento reutilizable respaldado por evidencia, destilado del trabajo terminado.

Las aristas tipadas conectan estos nodos en un grafo, con los bloques permaneciendo acíclicos. Esta estructura permite que Grove responda tanto ¿por qué existe esta tarea? como ¿qué se rompe si la cambio? sin depender del estado interno del agente.

Una vez que este grafo existe, el enrutamiento prometido anteriormente se vuelve mecánico. grove next elige el paso actual; grove packet emite exactamente su contexto. Nada irrelevante entra en la ventana de contexto.

Antes de tocar una línea de código, el agente consulta el cono de causalidad. grove packet W-NN --cone mapea el cono hacia atrás (todo lo que debe terminar primero, en orden de contracción topológica), el cono hacia adelante (el radio de explosión si este elemento cambia) y una puntuación de fragilidad por objetivo afectado.

Convierte el razonamiento en conocimiento reutilizable

Grove introduce una metodología unificada para el desarrollo de software impulsado por IA, basada en Dual-Track Agile, Hypothesis-Driven Development, ADRs, Continuous Discovery, Cynefin y el método Mikado. Estas influencias se integran en un único flujo de trabajo diseñado en torno a las limitaciones de los agentes LLM autónomos y se aplican mediante invariantes verificables por máquina.

La mayoría de los flujos de trabajo de IA son pequeñas cascadas: especifica todo, luego construye todo. Grove ejecuta el descubrimiento y la entrega en paralelo, alimentándose cada pista de la otra:

• Descubrimiento toma incógnitas abiertas y las operacionaliza. Una pregunta se convierte en una suposición falsable; los resultados validados se convierten en descubrimientos curados.
• Entrega ejecuta elementos de trabajo listos y escribe código verificado sobre esas suposiciones.

Las uniones son mecánicas. Las preguntas se plantean contra los objetivos; las suposiciones apuntan al trabajo y lo condicionan; los descubrimientos guían los siguientes objetivos; el trabajo terminado se destila de nuevo en descubrimientos. Cuando una prueba falsifica una suposición, el plan se reforma de inmediato; el trabajo dependiente no puede continuar sobre una base rota.

El conocimiento tiene un ciclo de vida

Grove no trata el conocimiento destilado como una verdad permanente. Los descubrimientos pueden volverse obsoletos a medida que el proyecto evoluciona; reactivar uno requiere un ancla fresca. La deuda de destilación se rastrea en lugar de acumularse silenciosamente, mientras que la aptitud del objetivo se vuelve a derivar en cada cierre.

El panel refleja el estado real del protocolo después de cada mutación, no el estado previsto. Grove asume que un proyecto sigue en movimiento: el conocimiento cambia, las suposiciones se invalidan y el razonamiento inconcluso se acumula. El protocolo hace visibles esos cambios en lugar de dejarlos desaparecer en el historial del proyecto.

Ideas detrás del protocolo

• El Descubrimiento y la Entrega se ejecutan en paralelo (Dual-Track Agile, Cagan). Un elemento de trabajo no puede entrar en Entrega hasta que cada pregunta abierta y suposición no validada que lo bloquee se resuelva en Descubrimiento.
• Cada unidad ejecutable tiene criterios de aceptación explícitos antes de que se escriba código (HDD, Definition of Ready). El DoR no es una lista de verificación que cualquiera pueda anular; es una conjunción booleana que la CLI evalúa en cada transición status=progress.
• Las decisiones de diseño de larga duración son artefactos de primera clase (ADR, Nygard). Las decisiones son inmutables una vez aceptadas. No pueden revisarse silenciosamente; solo pueden ser reemplazadas por una nueva decisión con una justificación registrada.
• Las incógnitas abiertas son artefactos de primera clase; los agentes las declaran en lugar de pretender saber (Continuous Discovery; Cynefin). Una pregunta etiquetada como chaotic detiene al agente y requiere resolución humana.
• Las suposiciones son compuertas falsables, no comentarios. Una suposición en estado invalidated_blocking impide que cualquier elemento de trabajo dependiente esté listo. El agente no puede continuar ignorándola.
• La refactorización utiliza un grafo de dependencias estilo Mikado que distingue causalidad, secuenciación, implementación e indagación. Esto hace explícito el radio de impacto de un cambio antes de tocar la primera línea.
• Los objetivos verificados se archivan solo después de la destilación: sus suposiciones validadas, preguntas respondidas y decisiones aceptadas se convierten en Descubrimientos (Y), axiomas de dominio curados que nunca se archivan y que alimentan paquetes futuros.
• Las Áreas (A) son un esqueleto de alcance permanente por encima de los objetivos. Cada objetivo pertenece exactamente a un área, aplicado por la CLI en la creación (I₁₃); las áreas nunca se archivan, por lo que la estructura sobrevive a cualquier objetivo individual.

Más allá del desarrollo impulsado por especificaciones

El desarrollo impulsado por especificaciones hace explícitas las especificaciones. Grove va un paso más allá: hace que el proceso de desarrollo en sí mismo sea ejecutable y verificable.

Una especificación describe lo que el sistema debería hacer. Grove además modela el estado del trabajo a su alrededor: qué está probado, qué se asume, qué está bloqueado, qué está listo, qué está hecho y sobre qué evidencia. Estas no son instrucciones para que el agente las siga; son estado del protocolo que condiciona lo que el agente puede hacer a continuación.

Esto cambia el flujo de trabajo de ejecución impulsada por documentos a ejecución impulsada por estado. No hay una única especificación para regenerar el proyecto ni una cascada fija por característica. El descubrimiento y la entrega se ejecutan continuamente, y cuando una suposición se falsifica, el grafo y el plan de ejecución cambian con ella. Cada transición de estado está mecánicamente condicionada en lugar de depender de que el agente siga el proceso correctamente.

Las especificaciones siguen siendo útiles. En Grove, pueden vivir como decisiones, criterios de aceptación y otro conocimiento estructurado del proyecto adjunto al trabajo. Lo que cambia es lo que las aplica: la especificación describe el resultado previsto; el protocolo determina si el proyecto puede avanzar.

Deja que la evidencia decida cuándo el trabajo está hecho

Una tarea ni siquiera puede comenzar hasta que pase una Definition of Ready. Esta es una conjunción booleana estricta evaluada por el protocolo en cada transición status=progress, no una lista de verificación que cualquiera pueda anular. Una vez lista, Grove emite un paquete de ejecución: exactamente el contexto que el paso necesita (el elemento de trabajo, sus criterios de aceptación, sus preguntas abiertas, su cadena de suposiciones y las decisiones que lo restringen) y nada más.

El cierre requiere evidencia falsable: salidas de pruebas, hashes de confirmación, registros de compilación. Un finished autoinformado no se acepta. La transición a done es atómica; los deltas de aptitud del objetivo y la re-derivación de estado se aplican en la misma escritura, o no se aplican en absoluto.

Razonamiento versionado, no solo código versionado

Todo el estado vive en .grove/state.lock, un único archivo de texto orientado a líneas con una suma de verificación SHA-256 reescrita en cada mutación. Cualquier edición manual, script rogue o fusión defectuosa se detecta en la siguiente operación del protocolo, y todas las transiciones de estado se bloquean hasta que el archivo se repare.

El archivo de bloqueo puede vivir dentro del repositorio del proyecto, de modo que el historial del razonamiento del proyecto evolucione junto con el código, o fuera de él en un directorio o repositorio separado. Ambas topologías son compatibles. Cuando se confirma en el control de versiones, el historial del archivo de bloqueo se convierte en el historial del razonamiento del proyecto, no solo de su código.

Conflictos de fusión y condiciones de carrera

Una carrera típica ocurre cuando dos ramas avanzan el estado del proyecto de forma independiente:

1. La rama A se fusiona en main y avanza el estado del proyecto.
2. La rama B se creó antes y aún contiene la suma de verificación del estado anterior.
3. Fusionar las ramas produce una discrepancia de suma de verificación.

Grove detecta la divergencia en lugar de aceptar silenciosamente un estado inconsistente.

La resolución es mecánica:

1. Resuelve los conflictos textuales, conservando registros de ambos lados.
2. Ejecuta grove repair --confirm para re-canonicalizar y re-calcular la suma de verificación del estado.
3. Ejecuta grove check para revelar cualquier violación de invariantes.
4. Ejecuta grove renumber si ocurrieron colisiones de ID entre ramas.

Trabajo paralelo

Para árboles de trabajo paralelos, grove init --id-stride/--id-offset asigna rangos de ID disjuntos para que las colisiones no ocurran en primer lugar.

En una sola máquina, las mutaciones concurrentes están protegidas por un flock exclusivo, mientras que el trabajo reclamado está protegido por tokens de sesión.

Las escrituras multi-máquina en un solo archivo de bloqueo están fuera de alcance por diseño. Las transiciones de estado remoto deben enrutarse a través de un único escritor canónico, como un agente CI primario.

Historial ejecutable, no solo un registro de auditoría

Git versiona código. Grove versiona el razonamiento que lo produjo. La mayoría de los harnesses de agentes y herramientas SDD (Spec-Driven Development) pierden el "por qué" en el momento en que se cierra una tarea. Grove registra cada acción en un diario persistente y ejecutable, brindándote algo sin precedentes: un deshacer y reproducir completo a nivel de decisiones del proyecto.

Cada mutación agrega una línea JSON a .grove/journal.log que contiene el comando, la marca de tiempo UTC, el token de sesión que la escribió y el inverso exacto del cambio.

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

Debido a que cada registro lleva su propio inverso, el diario es ejecutable. grove undo reproduce estos inversos en orden inverso, restaurando el estado anterior exacto hasta los estados de objetivo, deltas de aptitud y reclamos de sesión. Git revierte la implementación; Grove revierte la hipótesis, el estado de la suposición y la aptitud del objetivo que la justificaron.

Esto desbloquea una verdadera reproducción del proyecto. Puedes tomar el estado en t=0 y reproducir el diario para ver exactamente cómo el proyecto llegó a su forma actual. Actúa como un git blame para decisiones: en lugar de solo ver quién escribió una línea de código, reconstruyes qué suposición se validó, qué evidencia forzó un giro y por qué se eligió un camino específico.

El diario también captura el trabajo invisible del agente. Cuando la guardia de Definition of Ready (DoR) rechaza una transición, el diario registra los conjunctos exactos que fallaron. Los registros de auditoría, como ejecuciones de compuertas, rechazos y deshaceres, nunca se invierten ni se truncan. Esto captura lo que el agente intentó, no solo lo que cambió.

Este rastro persistente alimenta grove log y grove stats: reconstruyendo tiempos de ciclo, tasas de primera pasada del DoR y salud del contenido en cualquier punto de la historia. Debido a que está escrito en líneas JSON simples, no requiere permisos especiales para leer, sirviendo como materia prima para construir tus propias métricas o realizar análisis post-mortem de patrones de fallo de agentes.

Continúa cuando el agente desaparece

Un elemento de trabajo en progreso lleva un token de sesión exclusivo (solo la sesión que lo reclamó puede mutarlo). Si un proveedor se cae a mitad de un objetivo, o una refactorización difícil requiere un modelo diferente, otro agente en otro cliente toma el control mediante grove handoff. Alternativamente, adopta la sesión mediante grove resume.

Todo el razonamiento y la prueba viven en el archivo de bloqueo, por lo que grove next y grove packet reconstruyen el contexto de trabajo al instante. Los invariantes mantienen honesto al nuevo agente; el resto del progreso no puede falsificarse.

La verdadera prueba del desarrollo impulsado por agentes es exactamente esta: cuando el agente se detiene a mitad de un objetivo, el siguiente retoma el proyecto sin reconstruir la intención a partir de registros de chat.

Preserva por qué existe el trabajo

El resultado no es solo continuidad para los agentes. Es explicabilidad para las personas que poseen el proyecto.

Puedes responder por qué existe un fragmento de código, de qué depende, sobre qué suposiciones se apoya y qué evidencia lo justificó meses después de que se completó el trabajo original.

Primeros pasos

Grove está diseñado para instalarse una vez y luego usarse como la capa de flujo de trabajo persistente para tu proyecto.

La guía de instalación cubre la CLI, el servidor MCP, la aplicación de escritorio y el paquete de habilidades del agente. Luego ejecuta grove init en la raíz de tu proyecto para crear el archivo de estado con suma de verificación. Conecta el servidor MCP, agrega la habilidad firmada y arranca tu primera sesión con una plantilla de prompt. A partir de entonces, grove next impulsa cada sesión.

¿No estás seguro de si Grove se ajusta a tu flujo de trabajo? El Gemini Notebook contiene la documentación completa. Comienza con una pregunta simple, como "¿Cómo evita Grove que un agente marque trabajo como hecho sin evidencia?" o "¿Cuándo es Grove la herramienta equivocada para mi proyecto?"

Dónde encaja

Grove es más útil cuando el trabajo es de larga duración, intensivo en razonamiento y realizado por agentes autónomos.

Flujos de trabajo de seguridad e investigación: el trabajo de seguridad se extiende durante meses y se ejecuta sobre hipótesis: la mayoría de las pistas mueren, algunas se convierten en caminos críticos. Grove se ajusta a esta forma de manera nativa. Cada elemento cerrado lleva evidencia, por lo que el rastro de auditoría es el proyecto mismo: el diario de solo apéndice, las decisiones inmutables y los cierres vinculados a evidencia responden "quién concluyó qué, cuándo y sobre qué base" sin un proceso de informes separado. Las prioridades dejan de ser una sensación: el camino crítico, la aptitud por objetivo y las compuertas DoR deciden qué se ejecuta a continuación, formalmente. Trabajo de arquitectura y cumplimiento: las suposiciones en Grove llevan un método de validación y un resultado; las decisiones llevan una justificación; los descubrimientos anclan invariantes a superficies concretas. "¿Seguimos cumpliendo nuestros SLOs?" se convierte en una pregunta que el estado responde a través de métricas de aptitud de objetivos, y "¿por qué está construido así?" sigue siendo respondible meses después: cada elección arquitectónica apunta a las preguntas, suposiciones y evidencia que la produjeron.

Refactorizaciones largas y funciones de múltiples sesiones: el grafo de dependencias estilo Mikado y el cono de causalidad hacen explícito el radio de impacto antes de la primera edición, y la continuidad de sesión permite que el trabajo sobreviva a cambios de agente y proveedor.

Grove suele ser la herramienta equivocada para prototipos de corta duración, tareas de un solo prompt y proyectos donde el código no sobrevivirá a la sesión.

Grove no es un gestor de tareas, una herramienta de contexto de código ni un orquestador multiagente. Es un protocolo para mantener estado de proyecto verificado para agentes autónomos.

Invariantes del 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.

con terminalidad:

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⁺ es la variante estricta utilizada para aristas blocks: un objetivo declined no desbloquea dependientes. Otras relaciones usan la variante laxa terminal.

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 }

Preguntas frecuentes

¿Cómo funciona el archivo de estado?

Todo el estado vive en .grove/state.lock, un único archivo de texto orientado a líneas con una suma de verificación SHA-256 en cada escritura. Cualquier edición manual se detecta inmediatamente en la siguiente operación del protocolo, y todas las transiciones de estado se bloquean hasta que el archivo se repara. El agente nunca lee ni escribe el archivo directamente; interactúa solo a través de las interfaces de Grove (CLI, MCP).

Este diseño hace que todo el flujo de trabajo sea auditable y amigable con los diffs. Cada transición es una única escritura atómica. El archivo de bloqueo se puede confirmar en el control de versiones; su historial es el historial del razonamiento del proyecto, no solo de su código.

¿Cómo trabaja un agente con Grove de manera eficiente? ¿Necesita leer toda la habilidad y escribir ensayos en el bloqueo?

No en ambos casos. El index.md de la habilidad es el contrato mínimo seguro: una pantalla, completa para operar; cada otra página es profundidad que solo abres cuando la tarea toca su tema. Y cuando la forma de un comando no está clara, el propio CLI es el instructor: rechazos como add g: --area is required o DoR ≢ ⊤; see grove dor W-NN dicen exactamente qué falta. Incluso un agente que nunca abrió la habilidad no puede corromper el estado, porque los invariantes (puertas DoR, puertas de evidencia, la suma de verificación) son aplicados por el protocolo, no por el documento: la lectura parcial degrada la calidad del proceso, nunca la integridad.

Escribir funciona por compresión, no por transcripción. El agente delibera en su propio contexto todo el tiempo que necesite, y luego almacena solo las conclusiones: un criterio de aceptación por línea, una oración por hipótesis, un bloque compacto de contexto/opciones en un nodo de decisión. Docenas de llamadas CLI pequeñas son normales y baratas: se agrupan en una sola invocación de shell por nodo (add + campos + fitness). Lo que nunca pertenece al bloqueo es el razonamiento en sí: si un hecho no cambia lo que un agente futuro hace, no se registra. Y grove next / grove packet existen precisamente para que el agente nunca vuelva a leer el archivo de estado para planificar.

Licencia

GNU Affero General Public License v3.0 (AGPL-3.0). Copyright (c) 2026 Alex Shelepenok. Libre de usar, estudiar, modificar y redistribuir bajo los términos de la licencia, incluido el uso en red: ofrecer Grove como un servicio de red requiere ofrecer su código fuente. Consulta LICENSE para el texto completo.