alxshelepenok/grove

代码在生长。上下文窗口却不会。种下一片 Grove 🌳

Graph-driven Reasoning Over Verified Evidence。一种形式化工作流协议，旨在让深度、长期运行的项目在跨会话、跨代理、跨月的时间跨度中保持连贯。

长期运行的代理工作会以可预测的方式失败：随着会话增长，决策和假设逐渐脱离视野，代理会报告已完成的工作而实际上并未完成，几个月后代码库不再与任何人的认知相符，于是没有人能说清某一行代码为何存在。

Grove 适用于那些比单个会话更长寿、以推理为重的工作：长期重构、跨会话功能、安全与合规工作——在这些工作中，每个结论都需要可审计的痕迹。该协议会挑选下一步，因此你不必再向每一个新会话重新解释项目。

这为你带来：
- 原子化进展： 每项任务都经过机械验证，而不仅仅是声称完成。
- 层级优于压缩： 上下文被严格结构化，绝不进行有损摘要。
- 绝对可复现性： 每个操作都被记录，因此任何步骤、决策或假设都可以被重放和追溯。
- 跨代理的连续性： 如果某个代理在目标中途停止，另一个客户端或模型上的代理可以从已验证状态继续。
- 完全所有权： 每个目标、决策、任务、问题和假设都存储在一个持久的历史图谱中，完全归你所有。
Grove 将其规则作为确定性不变量强制执行，存储在单个带校验和的锁文件中：agent 无法在没有可证伪证据的情况下宣称工作已完成、启动未就绪的任务，或虚构进度。项目状态并非通过有损的提示压缩或摘要来保存，而是存在于一个带有机器可检查边的类型化推理图中，每一步都恰好接收其所需的执行包，不多不少。

可与 Claude Code、Codex、Gemini CLI、Cursor、Windsurf、Cline、GitHub Copilot 以及任何其他 agent 配合使用。Grove 包含一个 CLI、一个内置的 MCP 服务器，以及一个即插即用的 agent 技能包，因此你可以立即将其集成到你的工作区中。

[!IMPORTANT]
关于下面展示的桌面应用的一点说明。它的存在是为了让图、证据以及项目的健康状况一目了然，但它仍处于实验阶段，尚未在 macOS 上测试过。CLI 和 MCP 服务器是稳定且经过测试的接口。该 UI 在实现上不使用任何 JavaScript 框架，主要是纯 HTML、CSS 和 Tauri，这使其保持快速，并且图使用 WebGL 渲染。

实时探索的推理图。

包含历史记录、共 143 个节点时的同一视图。

agent 处理一个工作项所需的全部内容，仅此而已。

工作项从提案到完成全程跟踪。

每个领域的目标、工作与内容健康度。

按主题分组的工作，并标注关键路径。

随着项目增长，智能体会丢失上下文

长时间运行的智能体会遭受上下文失忆的困扰。随着会话增长，决策、假设和依赖关系会逐渐脱离视野。一个相关的失败模式是不可靠的自我报告：智能体在没有充分证据的情况下宣称工作已完成。这并非出于欺骗，而是因为环境中没有任何机制阻止它这样做。

标准的任务跟踪器天然信任执行者。当人类在 Jira 中勾选一个复选框时，工作就被假定为已完成。这对人类来说是合理的默认设定。但对自主智能体而言，这是一个隐蔽的失败模式。过早的“完成”声明在长时间会话中不断累积，最终演变为结构性错误，直到代码库不再与任何人所认为的样子相符，也没有人能说清某一行代码为何存在。

这不是理论上的问题。Grove 从一个粗糙的 Markdown 假设演变为一套协议，如今管理着 Merlin Guild——一个闭源生产项目，拥有 20 万行以上的 Rust 和 TypeScript 代码，大量涉及区块链和密码学。它之所以能够扩展，是因为该协议不依赖于智能体记住或正确遵守工作流程。

结构化，而非压缩

对上下文失忆的显而易见回应是增加工具：摘要、压缩、检索。所有这些都在压缩上下文，而压缩会丢失信息，同时寄希望于丢失的部分无关紧要。

Grove 不压缩上下文。它结构化上下文。

随着项目演进，其工作被持续组织为领域、目标、问题、假设、决策和可执行的工作项。这种层级结构让智能体能够识别与当前步骤相关的上下文，而不必反复将整个项目历史带入其上下文窗口。

结果不仅是更好的连续性；它还减少了 token 使用量。智能体不再仅仅为了恢复自己所处的位置以及当前任务为何存在而加载无关的项目上下文。

用一条提示词映射整个代码库

当你将一个前沿模型指向一个附带了 Grove 的原始代码库时，会发生什么？

没有协议时，智能体会略读文件，幻觉出一个快速摘要，几步之后就迷失方向。有了 Grove，它就能绘制出整个版图。在一个复杂代码库的真实测试中，一条提示词启动了一次长达 5 小时的自主 Discovery 会话。
智能体耗尽了其上下文窗口限制，但结果是一个完全填充的推理图：44 个领域、47 个目标和 89 个工作项，针对测试覆盖缺口和逻辑缺陷。它不只是倾倒了一份扁平化的待办事项清单；它正式将其未解之谜声明为问题，并将相关工作分组为主题。

以下是用于引导该项目的精确提示词：

加载 Grove 技能并连接到 MCP 服务器。完整研究该技能以理解协议约束。

你的目标是在整个代码库中运行完整的发现阶段。暂时不要编写实现代码，你的工作是项目分析和图构建。

1. 将项目分解为领域。注意，单个包可能包含多个逻辑领域。
2. 遍历每个领域并创建目标，以解决缺失的测试覆盖和明确的逻辑缺陷。
3. 对于每个目标，严格按照 Grove 协议格式创建工作项。
4. 将相关工作分组为主题。
5. 将未解之谜声明为问题，并在必要时将架构选择正式化为决策。

由于 Grove 强制执行就绪定义（DoR），智能体无法伪造进度。在接下来的一天里，智能体系统地执行了交付阶段，将 75 个任务转为已完成。其余任务正确地停滞在 proposed 或 ready 状态，等待人类回答智能体提出的阻塞性问题。

一个项目状态，多个界面

记忆的单位不是对话。而是项目。
进度的单位不是智能体的声明。而是经过验证的证据。

Grove 用严格的、机械执行的协议取代了礼貌的提示词指令。智能体通过 CLI、MCP 和桌面界面与项目状态交互。协议本身强制执行规则：

- 没有证据记录，工作项不能被标记为完成。
- 在每个前置条件都经过机器验证之前，工作不能开始。
- 目标进度不能手动更新；适应度增量在关闭时原子性地应用，否则完全不应用。

状态要么满足协议，要么 Grove 拒绝推进它。智能体不能仅仅通过声称工作已完成来推进协议状态。

只给智能体它们需要的上下文

Grove 强制智能体将产品分解为严格的类型化层级。不是原始的任务列表，每一部分规划上下文都明确地存在于节点分类法中。没有任何东西隐藏在旁支文档或智能体的内部状态中：

| 节点 | ID | 它包含什么 |
| --- | --- | --- |
| 领域 | A-NN | 目标之上的永久范围骨架；从不归档。 |
| 目标 | G-NN | 具有可衡量适应度函数的结果。 |
| 主题 | T-NN | 相关工作项的可选分组。 |
| 工作 | W-NN | 具有就绪定义 + 完成定义的可执行单元。 |
| 决策 | D-NN | ADR：一经接受即不可变，仅在有记录理由的情况下被取代。 |
| 问题 | Q-NN | 开放的未知项，被声明出来而不是假装不存在。 |
| 假设 | B-NN | 具有验证方法和结果的可证伪假设。 |
| 发现 | Y-NN | 从已完成工作中提炼出的可复用、有证据支持的知识。 |

类型化边将这些节点连接成图，同时保持块无环。这种结构让 Grove 既能回答 这个任务为什么存在？，也能回答 如果我改变它会破坏什么？，而无需依赖智能体的内部状态。

一旦这个图存在，上面承诺的路由就变得机械化了。grove next 选择当前步骤；grove packet 精确输出其上下文。任何无关内容都不会进入上下文窗口。

在触碰任何一行代码之前，智能体会查询 因果锥。grove packet W-NN --cone 映射出后向锥（所有必须先完成的内容，按拓扑收缩顺序）、前向锥（如果此项发生变化时的爆炸半径），以及每个受影响目标的脆弱性评分。

将推理转化为可复用知识

Grove 引入了一套面向 AI 驱动软件开发的统一方法论，其灵感来自双轨敏捷、假设驱动开发、ADR、持续发现、Cynefin 和 Mikado 方法。这些影响被整合到一个单一工作流中，该工作流围绕自主 LLM 智能体的约束而设计，并通过机器可检查的不变量加以强制执行。

大多数 AI 工作流都是小型瀑布：先规定一切，再构建一切。Grove 并行运行发现与交付，每条轨道都反哺另一条：

- 发现 接收开放的未知项并将其操作化。一个问题变成可证伪的假设；经过验证的结果变成经过整理的发现。
- 交付 执行已就绪的工作项，并在这些假设之上编写经过验证的代码。

这些接合点是机械化的。问题针对目标提出；假设指向工作并对其设门；发现指导下一批目标；已完成的工作又提炼回发现。当测试证伪一个假设时，计划会立即重塑；依赖的工作不能建立在破碎的基础上继续推进。

知识具有生命周期
Grove 不把蒸馏后的知识当作永久真理。随着项目演进，发现可能会过时；重新激活某项发现需要新的锚点。蒸馏债务会被跟踪，而不是悄悄累积，而目标适配度会在每次关闭时重新推导。

仪表盘在每次变更后反映的是实际协议状态，而不是预期状态。Grove 假设项目会持续演进：知识会变化，假设会被推翻，未完成的推理会累积。协议让这些变化可见，而不是让它们消失在项目历史中。

协议背后的理念

- 发现与交付并行运行（双轨敏捷，Cagan）。一个工作项只有在发现阶段解决了所有阻塞它的开放问题和未验证假设之后，才能进入交付阶段。
- 每个可执行单元在编写代码之前都有明确的验收标准（HDD，就绪定义）。DoR 不是任何人都能覆盖的检查清单；它是 CLI 在每次 status=progress 转换时求值的布尔合取。
- 长期存在的设计选择是一等工件（ADR，Nygard）。决策一旦被接受就不可变。它们不能被悄悄修改；只能由带有记录理由的新决策取代。
- 开放未知项是一等工件；智能体声明它们，而不是假装知道（持续发现；Cynefin）。标记为 chaotic 的问题会暂停智能体，并要求人工解决。
- 假设是可证伪的门禁，而不是注释。处于 invalidated_blocking 状态的假设会阻止任何依赖它的工作项变为就绪。智能体不能通过忽略它来继续推进。
- 重构使用 Mikado 风格的依赖图，区分因果关系、顺序、实现和探究。这会在触碰第一行代码之前明确变更的影响范围。
- 已验证的目标只有在蒸馏之后才会归档：其已验证的假设、已回答的问题和已接受的决策会成为发现（Y），即经过策展的领域公理，它们永远不会被归档，并会供给未来的信息包。
- 领域（A）是目标之上的永久范围骨架。每个目标恰好属于一个领域，由 CLI 在创建时强制执行（I₁₃）；领域永远不会被归档，因此该结构比任何单个目标都更长久。

超越规范驱动开发

规范驱动开发让规范变得明确。Grove 更进一步：它让开发过程本身可执行且可验证。

规范描述系统应该做什么。Grove 还额外建模围绕它的工作状态：什么已被证明、什么被假设、什么被阻塞、什么已就绪、什么已完成，以及基于什么证据。这些不是供智能体遵循的指令；它们是协议状态，用于门控智能体下一步被允许做什么。
这将工作流从文档驱动的执行转变为状态驱动的执行。不存在用于重新生成项目的单一规范，也不存在每个功能固定的瀑布流程。发现与交付持续进行，当某个假设被证伪时，依赖图和执行计划也随之改变。每一次状态转换都由机制把关，而不是依赖智能体正确地遵循流程。

规范仍然有用。在 Grove 中，它们可以作为决策、验收标准以及其他附加到工作上的结构化项目知识而存在。改变的是执行它们的主体：规范描述预期结果；协议决定项目是否被允许推进。

让证据决定工作何时完成

任务在通过就绪定义（Definition of Ready）之前甚至无法开始。这是一个由协议在每次 status=progress 转换时求值的严格布尔合取，而不是任何人都可以推翻的检查清单。一旦就绪，Grove 会发出一个执行包：恰好是该步骤所需的上下文（工作项、其验收标准、其未决问题、其假设链，以及约束它的决策），仅此而已。

关闭需要可证伪的证据：测试输出、提交哈希、构建日志。自我报告的 finished 不被接受。向 done 的转换是原子的；目标适应度增量和状态重新推导在同一次写入中应用，否则就完全不应用。

版本化的推理，而不仅仅是版本化的代码

所有状态都存放在 .grove/state.lock 中，这是一个面向行的单一文本文件，每次变更时都会重写一个 SHA-256 校验和。任何手动编辑、失控脚本或错误合并都会在下一次协议操作时被检测到，并且所有状态转换都会被阻止，直到该文件被修复。

该锁文件可以位于项目仓库内部，这样项目推理的历史就会与代码一同演进；也可以位于外部的单独目录或仓库中。两种拓扑都受支持。当提交到版本控制时，锁文件的历史就成为项目推理的历史，而不仅仅是其代码的历史。

合并冲突与竞态条件

典型的竞态发生在两个分支各自独立推进项目状态时：

1. 分支 A 合并到 main 并推进项目状态。
2. 分支 B 创建得更早，仍包含先前的状态校验和。
3. 合并这些分支会产生校验和不匹配。

Grove 会检测到这种分歧，而不是静默接受不一致的状态。

解决是机械化的：

1. 解决文本冲突，保留双方的记录。
2. 运行 grove repair --confirm 以重新规范化并重新计算状态校验和。
3. 运行 grove check 以暴露任何不变量违规。
4. 如果分支之间发生了 ID 冲突，运行 grove renumber。

并行工作

对于并行工作树，grove init --id-stride/--id-offset 会分配不相交的 ID 范围，从而从一开始就避免冲突发生。
在单台机器上，并发变更由独占 flock 保护，而已认领的工作由会话令牌保护。

跨机器对单个锁文件的写入在设计上不在范围内。远程状态转换必须通过单一规范写入者路由，例如主 CI 代理。

可执行历史，而不仅仅是审计追踪

Git 对代码进行版本控制。Grove 对产生代码的推理进行版本控制。大多数代理框架和 SDD（规范驱动开发）工具在任务关闭的那一刻就丢失了“为什么”。Grove 将每个操作记录到一个持久、可执行的日志中，为你提供前所未有的能力：在项目决策层面进行完整的撤销和重放。

每次变更都会向 .grove/journal.log 追加一行 JSON，其中包含命令、UTC 时间戳、写入它的会话令牌，以及该变更的精确逆操作。

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

因为每条记录都携带自己的逆操作，所以日志是可执行的。grove undo 按相反顺序重放这些逆操作，将状态精确恢复到先前状态，直至目标状态、适应度增量和会话认领。Git 回滚实现；Grove 回滚假设、假设状态以及为其提供依据的目标适应度。

这解锁了真正的项目重放。你可以取 t=0 时的状态并重放日志，以准确了解项目如何达到当前形态。它充当决策的 git blame：你不仅能看到谁写了某行代码，还能追溯验证了哪个假设、什么证据迫使转向，以及为什么选择某条特定路径。

日志还捕获代理的不可见工作。当就绪定义（DoR）守卫拒绝某个转换时，日志会记录失败的确切合取项。诸如门禁运行、拒绝和撤销之类的审计记录永远不会被反转，也永远不会被截断。这捕获了代理尝试了什么，而不仅仅是它改变了什么。

这条持久轨迹为 grove log 和 grove stats 提供支持：重建周期时间、DoR 首次通过率，以及历史任意时间点的内容健康状况。因为它以纯 JSON 行写入，读取无需特殊权限，可作为构建你自己的指标或对代理失败模式进行事后分析的原材料。

当代理消失时继续

进行中的工作项携带独占会话令牌（只有认领它的会话才能修改它）。如果提供商在目标进行中宕机，或者一次艰难的重构需要不同的模型，另一个客户端上的另一个代理可以通过 grove handoff 接管。或者，它通过 grove resume 采用该会话。

所有推理和证明都存在于锁文件中，因此 grove next 和 grove packet 会立即重建工作上下文。不变量让新代理保持诚实；其余进展无法伪造。
Agent 驱动开发的真正考验正在于此：当 agent 在目标中途停止时，下一个 agent 能够接手项目，而无需从聊天记录中重建意图。

保留工作存在的原因

其结果不仅是 agent 的连续性，更是对项目所有者而言的可解释性。

你可以回答一段代码为何存在、它依赖什么、它基于哪些假设，以及是什么证据在原始工作完成数月后仍能证明其合理性。

快速开始

Grove 的设计理念是一次安装，然后作为项目的持久化工作流层使用。

安装指南涵盖了 CLI、MCP 服务器、桌面应用和 agent 技能包。然后在项目根目录运行 grove init 以创建带校验和的状态文件。连接 MCP 服务器，添加已签名技能，并使用提示模板引导你的第一个会话。从那时起，grove next 将驱动每一个会话。

不确定 Grove 是否适合你的工作流？Gemini Notebook 包含完整文档。从一个简单的问题开始，比如“Grove 如何阻止 agent 在没有证据的情况下将工作标记为完成？”或“什么时候 Grove 不适合我的项目？”

适用场景

当工作具有长期性、推理密集型且由自主 agent 执行时，Grove 最为有用。

安全与研究类工作流：安全工作跨越数月，并建立在假设之上：大多数线索会消亡，少数会成为关键路径。Grove 原生契合这种形态。每个已关闭条目都携带证据，因此审计轨迹就是项目本身——仅追加日志、不可变决策和证据绑定的关闭操作，无需单独的汇报流程即可回答“谁在何时基于什么依据得出了什么结论”。优先级不再是一种感觉：关键路径、按目标的适配度和 DoR 门控以形式化方式决定接下来运行什么。

架构与合规工作：Grove 中的假设携带验证方法和结果；决策携带理由；发现将不变量锚定到具体表面。“我们是否仍然满足 SLO”成为状态通过目标适配度指标来回答的问题，而“为什么这样构建”在数月后仍然可回答——每个架构选择都指向产生它的问题、假设和证据。

长期重构与多会话功能：Mikado 风格依赖图和因果锥在第一次编辑之前就使影响范围变得明确，而会话连续性让工作能够在 agent 和提供商变更后存续。

对于短生命周期原型、单提示任务，以及代码不会比会话存续更久的项目，Grove 通常是错误的工具。

Grove 不是任务管理器、代码上下文工具或多 agent 编排器。它是一种为自主 agent 维护已验证项目状态的协议。

协议不变量

I₁:  ∀ w ∈ W 且 status = progress，DoR(w) ≡ ⊤。
I₂:  ∀ w 且 type = spike ∧ status = done，
produces(w) ⊆ D ∪ Q ∪ B ∪ Y  ∧  produces(w) ≠ ∅。
I₃:  ∀ w 且 status = done，∃ ev ∈ Evidence，satisfies(ev, AC(w))。
I₄:  |{ w ∈ W : status(w) = progress }| ≤ WIP_LIMIT（默认 2）。
I₅:  ∀ (n₁, blocks, n₂) ∈ E，terminal⁺(n₁) 先于 status(n₂) 可转换为 progress。
I₆:  ∀ t ∈ T，status(t) = done ⟺ ∀ w ∈ WI(t)，status(w) ∈ { done, rejected, archived }。
I₇:  图 (N, E ∩ (· × {blocks} × ·)) 是一个 DAG。
I₈:  ∀ q ∈ Q 且 cynefin(q) = chaotic，状态转换仅通过 human 进行。
I₉:  ∀ w ∈ W 且 type = feature，DoR(w) ⇒
∀ b ∈ BChain(w)，status(b) ∈ { validated, invalidated_acceptable }。
I₁₀: 状态转换 w → done 与将 fitness 增量应用于每个 g ∈ goals(w)
并重新推导 status(g) 是原子的。要么两者都成功，要么两者都不成功。
除非增量在同一次调用中暂存（或自 w 上次状态变更以来通过
grove fitness 预先暂存），否则 CLI 拒绝 status=done。
I₁₁: ∀ w ∈ W 且 status = progress，设置该状态的会话是唯一
被允许变更 w 的会话，直到 terminal(w) 或 w 离开 progress
（例如 revert 或另一次受保护的状态变更）。持久化为头部
属性 session 和 session_at（UTC）；check 拒绝缺失的令牌
（grove resume 采用；见协议 §2.6）。
I₁₂: ∀ y ∈ Y：(≥1 条溯源边：(w, produces, y) ∨ (y, distills, d/q/b))
∧ (surface(y) ≠ ∅ ∨ why(y) ≠ ∅) ∧ tags(y) ≠ ∅（≥1 个术语表术语）。
当任一合取项失败时，proposed → active 被拒绝；stale → active
仅通过以新锚点支付的 grove revalidate 进行。
I₁₃: ∀ g ∈ G：∃ a ∈ A 且 area(g) = a.id，记录为必填的 area
字段并在创建时强制执行（grove add g --area=A-NN）；通过
grove set G-NN area=A-NN 重新分区。锁中无 area 的目标是
违规，绝不静默修复。

带有终止性：

terminal(w ∈ W)  ⟺ status(w) ∈ { done, rejected, archived }
terminal⁺(g ∈ G) ⟺ status(g) = verified（对 blocks 边严格）
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)  ⟺ ⊥（area 没有生命周期）

terminal⁺ 是用于 blocks 边的严格变体：declined 的目标不会解除依赖项的阻塞。其他关系使用宽松的 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)       ≜ 如 w 的 goals 字段中所记录
WI(t)          ≜ { w ∈ W | theme(w) = t }

FAQ

状态文件如何工作？
所有状态都保存在 .grove/state.lock 中，这是一个单行导向的文本文件，每次写入都带有 SHA-256 校验和。任何手动编辑都会在下一次协议操作时立即被检测到，并且在文件修复之前，所有状态转换都会被阻止。智能体从不直接读写该文件；它仅通过 Grove 接口（CLI、MCP）进行交互。

这种设计使整个工作流可审计且对差异友好。每次转换都是一次原子写入。该锁文件可以提交到版本控制；它的历史就是项目推理的历史，而不仅仅是代码的历史。

智能体如何高效地使用 Grove？它需要阅读整个技能并把文章写入锁文件吗？

两方面都不需要。该技能的 index.md 是最小安全契约——一屏内容，操作上完整；其他每一页都是深度内容，只有当任务涉及其主题时才打开。当某个命令的形式不明确时，CLI 本身就是指导者：像 add g: --area is required 或 DoR ≢ ⊤; see grove dor W-NN 这样的拒绝信息会准确说明缺少什么。即使是从未打开过该技能的智能体也无法破坏状态，因为不变量（DoR 门、证据门、校验和）由协议强制执行，而不是由文档强制执行——部分阅读会降低流程质量，但绝不会损害完整性。

写入依靠压缩，而不是转录。智能体在自己的上下文中根据需要长时间思考，然后只存储结论：每行一条验收标准，每个假设一句话，决策节点上一个紧凑的上下文/选项块。数十次小型 CLI 调用是正常且低成本的——它们按节点批量合并为一次 shell 调用（add + 字段 + fitness）。绝不属于锁文件的是推理本身：如果一个事实不会改变未来智能体的行为，它就不会被记录。而 grove next / grove packet 的存在正是为了让智能体永远不必重新读取状态文件来进行规划。

许可证

GNU Affero 通用公共许可证 v3.0（AGPL-3.0）。版权所有 (c) 2026 Alex Shelepenok。根据许可证条款，可自由使用、研究、修改和再分发，包括网络使用：将 Grove 作为网络服务提供需要提供其源代码。完整文本见 LICENSE。