gpp (把 git++)

AI 智能体在持续地修改代码，同时总是会丢失两次提交之间发生的工作；你为了代码库而做的那些笔记（CLAUDE.md、记忆库、知识文件）也会在代码往前演进之后悄然过期。gpp 正是为这一现实而构建的版本控制系统：它在每次变更发生的那一刻就捕获它，带显式意图、作者类型（人/智能体）和成本记录的精选变更集，然后promote（提升），并把项目知识托管在仓库自身的提交历史之上——因此，当某个提交把一条你认为成立的“关于代码的信念”推翻时，gpp 能直接指出是哪个提交。

（录屏由 scripts/demo.sh 生成——确定性，可复现，没有任何模拟。）

30 秒速览

cargo install gpp-cli

gpp init --graphex
echo "fn main() {}" > main.rs
gpp timeline                     # captured already — no staging, no commit
gpp promote -m "first cut" --intent feature
gpp diff HEAD                    # semantic diff: renames/moves are one op

而另一个其他 VCS 都不会做的事——把你对代码的信念记下来，让提交历史去审核它：

gpp belief add --claim "token expiry is 24h" --evidence src/auth.rs:7-7
# ...weeks of commits later...
gpp belief bisect "token expiry is 24h"
# INVALIDATED  cs:fhcpef7c  "raise token expiry to 7 days"
#  -     7 | pub const EXPIRY_HOURS: u64 = 24;
#  +     7 | pub const EXPIRY_HOURS: u64 = 168;

完全确定——只有 diff 交集和 blob 哈希，零 LLM 调用、零网络请求。（供对比：让最前沿的模型去判断某条存储下来的认知是否已经失效，它在 STALE benchmark 上最高只有 55.2% 的准确率——而在 gpp 中这只是一次历史查询，并不是一次模型判断。）这种方法已经用四个语言、五个真实仓库的 hiki后续验证过——xn"axum 0.6→0.7、flask 1.1→2.0、clap 3→4、zod 3→4、go-redis 8→9——其中每一条失效的信念都能二分定位到一个固定、可查的“元凶”提交，而对照组的控制条件不受影响。完整验证矩阵见 demos/belief-bisect/。

Related MCP server: yksanjo/gmem

它不同于哪几个地方 where we differ

• 持续捕获。 一条高分辨率“时间线”记录着每一次文件变更（SQLite WAL、防抖 watcher）；经筛选的变更集会被*promote（提升）*出来，并带明确的目的、作者类型以及成本记录。commit 与 commit 之间没有任何东西会丢失。

• Graphex：有版本、可加密的项目知识。 架构、约定、决策和信念都驻留在仓库内一个加密的知识图谱中，按智能体的信任层级做分级门控，每次读取都有审计记录，并持续接受提交历史中的过期检查。

• 智能体治理。 agent 有一等公民身份、信誉打分；合规即代码（compliance-as-code）策略在 capture/promote/sync 三边强制实施；并支持异常检测与每个变更集各自的 token/成本归因。

除了上面的，任何其余部分——Noise 上的 P2P 同步、replay、评审/RBAC、中继节点、TUI——都是底层平台支撑的：见 docs/ARCHITECTURE.md。

Git 是底座，不是对手。 桥（gpp git-import / git-export / git-bridge）与真实 Git 提交完整畅通、双向往返。因此 GitHub 和现有工作流照常使用——gpp 的知识层、溯源层和治理层则是搭在旁边延伸。前方的 axum 演示就是全部跑在通过这座桥导入的真实历史。

接入 Claude Code（或任何 MCP 客户端）

GPP 随包带来的 MCP 服务；智能体可以查询图谱（每一条信念都带有一个“新鲜度信封”——锚定 anchor、此刻到未来的 commits、以及让麻醉失效掉的那条更改）、以 propose_belief 提交带有证据锚定的自己的信念（先经人类批准，然后交由历史去审检）、提出 changeset、并上报成本。只需要你仓库根目录的 .mcp.json 写成这样：

{
  "mcpServers": {
    "gpp": { "command": "gpp", "args": ["mcp-server", "--stdio"] }
  }
}

客户端完整设置（Claude Desktop、通用 stdio）和外部暴露的工具列表：docs/MCP.md。

状态

全部 9 个 ROADMAP 阶段（0–8）均已实现。 各阶段交付物与已记录的偏差说明，见 docs/ROADMAP.md；按优先级排队的积压工作见 docs/TODO.md；持续运行的工程日志见 docs/WORKLOG.md。

2026-08-23 检查：184 个 workspace 测试通过，cargo clippy 和 cargo fmt 干净无错，整个 workspace 可构建。不存在摆烂的 crate——每个 crates 都有可用实现。覆盖率被 CI 所计量（cargo llvm-cov；基线行为 65.7% line，正在提高）。

测试深度仍不均：基础层覆盖度良好（gpp-core、gpp-graphex、gpp-diff、gpp-tui 均有 ≥ 80% 的行覆盖率；CLI 有端到端磨坊：政策执行、成本统计、审查指派、以及信念二分），而有些集成 crate 仍停留在 smoke 层级（gpp-sdk、gpp-notify、gpp-rbac、gpp-replay）。这里的“已实现”是指达到了它的 milestone，不是所有部分都彻底加固过。补上这个 gap 正是 docs/TODO.md 的第一优先级。

全帧分层表

以及：extensions/{gh-gpp,vscode-gpp,neovim-gpp}、GitHub Actions + GitLab CI 模板、deploy/ Docker 镜像、packaging/ Homebrew。

已记录在案但还未安排（它们被收进 ROADMAP/TODO，而不是无声跳过）：依赖的 registry/许可证 API、原生 PyO3/napi bindings、对外出的语义层 review sync、apt/dpkg 安装包。

安装 / 构建

cargo install gpp-cli                    # the `gpp` binary (crates.io)
cargo install gpp-relay                  # relay node (optional)

# or from a clone
cargo build --release
cargo test --workspace
cargo bench -p gpp-core -p gpp-diff      # criterion perf suite

预编译二进制（Linux、macOS ARM+Intel、Windows）随每次 release一起提供；cargo install --git https://github.com/mahabubulid/gpp gpp-cli 则一直能拿到未正式版本的最新开发版。

更多值得 尝试

# Governance
gpp policy template secrets-scan
gpp trust show
gpp audit --include-cost --include-graphex

# Decentralized: sync two repos over Noise
gpp sync serve 127.0.0.1:9473             # on peer A
gpp sync add a 127.0.0.1:9473 && gpp sync # on peer B

# GitHub-compatible
gpp remote setup --platform github --repository acme/webapp
gpp remote pr-create --base main

项目说明见 CLAUDE.md；完整 spec（架构、数据模型、CLI、协议、roadmap）见 docs/；用户手册与教程见 docs/book/。

许可证

MIT