
CommitLore
io.github.MongLong0214由 GitHub 账号 MongLong0214 发布v1.2.0更新于 Oct 27, 2026
Git-native decision memory for coding agents: only the decisions still in force for the edited path
概览
以 Git 为载体的决策记忆,只向编码代理提供其即将编辑路径上仍然有效的设计决策。
- 可以做什么
- 编辑前投递上下文:按代理即将改动的文件路径返回有效记录(约束、已否决的方案、警告)
- 捕获与校验:将草拟的决策记录与会话记录和暂存差异比对后再接受
- 以 Git 保存记录:把接受的记录存为提交 trailer 或 notes,而非托管记忆数据库
- 跟踪生命周期:区分有效、被取代和已过期的决策,并报告陈旧记录
- 评定可信等级:以指令、声明或扣留内容的形式投递,可选签名模式
- 通过 MCP 暴露捕获流程,供使用该注册的主机调用
- 适用场景
- 适合编码代理反复提出仓库已否决方案的团队,并希望这些理由随代码一起经过克隆、分支和评审。最适合有真实历史、且确有少量值得保留决策的仓库;大多数提交不会带记录。
- 运行要求
- 作为本地进程在用户机器上运行(仅桌面端)。需要 Node.js 22.23.2 或更高版本以及 Git,安装脚本会先检查两者。每个仓库需用 CLI 初始化,代理主机需接入插件或 MCP 注册。未声明托管后端、账号或 API 密钥。
安装
在 SourceWeft 中
- 打开 控制台中的 CommitLore,将其添加到工作区。
- 为需要使用其工具的对话启用该服务。
Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。
其他 MCP 客户端
参照 仓库 中的启动说明。
README
CommitLore
Stop re-reviewing the same bad idea.
Decision authority for coding agents, owned by Git.
Keep constraints, rejected alternatives, and warnings in Git — then deliver
only what is still in force, so an agent is not handed a decision the
repository already reversed.
No hosted memory. The repository owns the record.
[CI] [Latest release] [Protocol 2.0 Stable] [Node.js 22.23.2 or newer] [MIT License]
Install once. Then initialise each repository where you want it to work.
Prefer to read the installer first?
It installs a pinned source checkout and a wrapper that runs
node <checkout>/dist/commitlore.mjs — no compiled download, no build step.
The code survives. The judgment doesn't.
An agent proposes an approach. Your team rejects it because of a non-obvious constraint. The final code preserves the outcome, but usually not why the alternative was rejected. A later agent sees only the code and proposes the same idea again.
CommitLore keeps that judgment beside the code.
What CommitLore does
Most commits should carry no record. CommitLore is for judgment the code cannot preserve, not for narrating every change.
60 seconds to decision-aware agents
1. Install the CLI
macOS and Linux:
Windows:
Requires Node.js 22.23.2+ and Git. The script checks both before it writes anything.
2. Connect your agent
Claude Code:
Codex:
The plugin puts no commitlore on PATH, so the commands below need the CLI
install as well. The installers also detect and wire supported MCP hosts where
they can do so safely; the exact matrix is below.
3. Initialize a repository
Start a new agent session after installing or updating a plugin: a running session keeps the runtime it loaded.
Then work and commit normally. On supported skill integrations, CommitLore is considered during ordinary commit requests and stays silent when there is nothing worth preserving. You do not need to name CommitLore on every commit.
Want accepted records to stage without a per-record prompt? The repository can
opt in once with commitlore auto on. That policy is repository-owned and
applies to the team, so it is not silently enabled by this page.
What the agent receives
Before editing src/pricing.ts:
[claim] means "weigh this as information." A repository can opt into the
stronger signed-authority mode. Delivery gives the agent context; it does not
block the edit.
Why Git?
The repository should own the judgment behind its code.
CommitLore stores records in ordinary Git trailers and notes, so they branch, merge, clone, review, and survive provider changes with the code they explain.
SQLite is only a rebuildable index. Delete it and Git still holds the record.
Finding an old decision is not enough
A general memory or retrieval system asks:
Which old text looks related?
CommitLore asks:
Which recorded decisions still apply to this path now?
A superseded decision can be highly relevant and still be wrong as current guidance. Relevance and authority are different questions.
How it works
- Capture — an agent drafts only decision context the diff cannot show.
- Verify — CommitLore checks the draft against the session and staged diff.
- Preserve — the accepted record lives in Git with identity and lifecycle.
- Deliver — before a later edit, only active records for that path are returned.
Most commits carry no record. The commit hook validates a record when one is present; it does not invent one.
An existing hook is not overwritten. commitlore init honours core.hooksPath,
moves any hook already installed to <hook>.commitlore-chained, and calls it
first; commitlore hooks uninstall puts it back.
What happens automatically
"Available" means the prepare → verify → stage workflow exists. It does not mean every eligible commit is assessed automatically.
Users on supported skill hosts do not need to say "record this in CommitLore" on every commit. The remaining limitation is host initiation, not a required per-record user command.
Squash-merge repositories
A squash merge replaces a branch's commits with one new commit, and that commit does not carry the branch's trailers. If your repository merges with the squash button, a record made on a branch is dropped by the merge unless something carries it onto the commit that squashed it.
Two paths cover that, and one of them needs a one-time setup:
GitHub performs that merge on its own servers, where no local git hook runs at all, so the local hook cannot see it. The Action is the only place that has what it needs at that moment: the pull request, its commits, and the commit they were squashed into.
Add .github/workflows/commitlore-preserve.yml:
Two rules for whoever edits this next, because pull_request_target runs with a
writable token: never check out the pull request's head here, and never execute
anything reachable from refs/commitlore/pr-head. The fork's commits arrive as
data to read trailers from, not as code to run.
commitlore doctor reports whether this is switched on, under
squash inheritance. It says so before a record is lost;
squash conservation is the row that reports records already gone.
If you merge with merge commits or rebase, records survive on their own and this setup is unnecessary.
A field report, not a measurement
One run, on an unrelated repository, by someone installing v1.2.1 for the first time. Nothing here was measured and none of it is in the evidence logs. It is on this page because the paragraph above asserts a loop that no table here covers.
They asked an agent to fix a rounding bug, mentioned in passing that a decimal library had already been considered and dropped, and ended with "commit it". CommitLore was never named. Part of what the commit carried:
The Warn was not dictated to the agent. It hit the trap while working and left
it for whoever came next. Provenance: drafted records that no human read the
record, which grades it claim — delivered as a report to weigh, not an order.
A later session with no shared history was asked to adopt the decimal library
after all. It did not, and named the record as its reason. It also read the
grade: a claim is not an instruction, so it checked the stated reason against
the code before agreeing with it.
Unlike memory storage
CommitLore is intentionally narrower. It is not a general user-memory system, conversation archive, or vector database replacement.
Evidence
Index build time follows the number of records, not the number of commits: the expensive pass runs once per record, so a long history that has recorded little builds faster than a short one dense with records.
Path scope is what keeps a large history from reaching the model. On the #167 corpus, only 2 of 10,002 records did:
That measures exposure and recall at a fixed two-record budget — not token cost, billed cost, accuracy, or agent behaviour. One corpus, one query, one pinned embedding model.
The agent study does not establish a universal model effect. Delivery is not proof that a model read or followed a record.
Methods, full tables, exclusions, and negative results →
Limits, trust and privacy
- Capture is assisted, not deterministic. Supported skills consider ordinary commit requests, but no host is certified to assess every eligible commit.
- Default directive mode is not authentication. It matches the commit
author header, and anyone who can write a commit can set that header — so a
[directive]in default mode is policy metadata, not proof of identity. Signature mode additionally requires Git's own verified status and a match in the repository-localcommitlore.trustedSignerallowlist; an absent, empty, or unreadable signer allowlist authorizes nobody, so the mode fails closed. - Guard is an experimental advisory, not a safety net: precision 44.8% (95% Wilson CI 32.7%–57.5%), recall 22.0% on the 417-decision corpus. An empty guard result is not a safety verdict.
- Delivery spends tokens on every matching tool call. The pre-edit hook
fires on
Readas well asEdit,Write,MultiEditandNotebookEdit, so it runs far more often than an editing agent commits. Each fire spends up to the payload budget — 800 tokens by default, changed with--budget. A repository with no records spends nothing, which means this is a cost that arrives with adoption rather than with installation. - An answer may be partial. Coverage is disclosed; absence from a partial
result is not proof that no record exists.
commitlore coveragereports what a scan reached. - Commit trailers travel with a clone; notes do not. Git does not fetch
refs/notes/*by default, so a record inrefs/notes/commitloreis absent from an ordinary clone untilcommitlore initconfigures that mirror. - There is no hosted backend. But once the server or hook returns context, the host handles that context under its own policy; CommitLore does not control that data flow.
Security · Compatibility · Evidence
Security and trust model
Records are untrusted until graded. Default author matching is policy metadata, not authentication. Signed directive mode requires Git verification and a repository-local signer allowlist; an absent or unreadable allowlist authorizes nobody. Injection-shaped payload is withheld from model-readable routes.
Installation, upgrades, and old hook generations
The CLI installer cannot rewrite hooks inside repositories it does not know
about, and running host sessions retain the runtime they loaded. commitlore doctor names both states and their repair, and commitlore upgrade reports
whether a newer release exists.
Protocol and Git storage
Records are ordinary Git trailers or notes. Protocol 2.0 defines lifecycle, trust grades, validation, and compatibility.
Evidence and negative results
The repository publishes the methods, exclusions, unsuccessful measurements, and the cases where the original benchmark or diagnosis was wrong.
Try it on a repository with history.
Tell us where path scope, lifecycle, capture, or installation breaks.
Report a failure case · Read the self-audit
Documentation
- Install, upgrade, and uninstall
- CLI reference
- Capture workflow
- Record protocol
- Security model
- Evidence and limitations
- Production contract
Contributing
CONTRIBUTING.md covers the record protocol this repository holds itself to, the release gate, and how to reproduce the evidence.
License
MIT — see LICENSE.
来源:README.md,提交 b18c40f
工具
0版本历史
1- v1.2.0最新Sep 16, 2026
评分
已满足适用检查项的 50%
该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。
- 近 30 天内可连通25 分
请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。
- 已声明认证方式10 分
请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。
- 已列出工具15 分
请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。
- 描述必需15 分
- 图标10 分
- 文档15 分
- 许可证10 分