
koment
io.github.koment-dev由 GitHub 帳號 koment-dev 發布v3.2.0更新於 Oct 24, 2026
Read and write checked code rationale stored outside source comments.
概覽
讓助理讀取與寫入存放在原始碼註解之外、經過檢查的程式碼理由,並錨定到它所解釋的具體程式碼行。
- 可以做什麼
- koment 把程式碼背後的原因記錄為 .koment/ 中的 YAML 註解,錨定的是程式碼片段而不是行號。這個 MCP 伺服器提供讀取工具(koment_get、koment_search、koment_repositories),在寫入模式下還提供變更工具(koment_add、koment_reanchor、koment_convert_comment、koment_acknowledge_comment)。當被註解的程式碼變更時,koment check 會把註解回報為 drifted、ambiguous 或 orphaned 並以非零狀態結束,避免過時的理由被悄悄沿用。
- 適用情境
- 當助理要修改程式碼,而你希望這些程式碼背後的理由始終附著並受到檢查時使用;也適合希望代理記錄變更原因、而不是留下解釋性註解的場景。適合已經把註解保存在 git 中、並希望代理讀寫同一批記錄的團隊。
- 執行需求
- 以本機 stdio 程序執行,通常透過 koment 執行檔,或使用 docker 執行容器映像 ghcr.io/koment-dev/koment:3.2.0。本機指令需要一個 git 檢出目錄,koment 會從工作目錄往上尋找所屬檢出目錄。寫入模式需要 --write 旗標或 KOMENT_WRITE。本機使用未宣告需要帳號或 API 金鑰。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 koment,將其新增到工作區。
- 為需要使用其工具的對話啟用該服務。
Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。
其他 MCP 客戶端
參照 儲存庫 中的啟動說明。
README
koment
Keep the why next to your code — checked, so it can't quietly rot.
[Release] [CI] [OpenSSF Scorecard] [Open VSX] [License] [Annotations]
The problem
Someone wrote retry 5 times instead of 3, and there was a good reason. Six
months later nobody remembers it, so it gets "simplified" back to 3 and the bug
returns.
A comment was supposed to prevent that. Comments rot: they sit next to the code without being attached to it, and when the code changes nothing tells you the comment just became a lie. Your AI agent then reads that lie and acts on it.
What koment does
You record the reason outside the source, anchored to the exact lines it explains. Then koment watches those lines. Change them, and it says so:
Exit code 1. The build stops. Nobody silently inherits a reason that no longer describes the code.
The records are YAML in .koment/, in your git repository. No database, no
service, no account. They review in the same pull request as the change that
motivated them.
See it running → — koment's own annotations, published by a workflow you can copy.
For AI agents
This is where it earns its keep. Agents write explanatory comments constantly, and they edit code without reading why it was written that way. koment makes both of those fail immediately, while the agent is still working:
- It writes a comment → the edit is refused, with instructions to record the reasoning as an annotation instead.
- It edits annotated code without checking → the turn cannot finish until the annotation is revisited.
One MCP server serves Claude Code, Cursor, Codex, opencode, Hermes, Zed and the rest, so every agent reads the same reasoning through the same interface. Set yours up →
Humans get the same loop in the editor: a squiggle under the comment, and a quick fix offering convert to annotation or keep it, on the record.
Install
Other ways
In GitHub Actions, uses: koment-dev/koment@v3. Or take a checksum-listed
binary for Linux, macOS or Windows on amd64/arm64 from the
latest release — every
other channel is built from those same artifacts.
Try it in a minute
From inside any git repository:
That sets up .koment/ and wires whichever agents you use. Now record a reason
and watch it get checked:
Now edit that line and run koment check again. It fails, and tells you
which reasoning no longer matches its code. That is the entire product; the rest
is delivering it to the people and agents who need it.
How it works
-
You annotate a snippet. koment records the prose, exact excerpt, surrounding source context, the commit you were on, and who you are.
-
The record lands in
.koment/annotations/<id>.yaml, one file per annotation. Concurrent agents create independent files instead of replacing one shared list. -
Resolution searches the current file for that excerpt and produces exactly one status:
-
koment checkexits non-zero onambiguous,driftedororphaned. That is the whole mechanism: uncertain rationale is worse than no annotation, so it has to be impossible to ignore. -
When it fails,
koment reanchor <id> --excerpt '<new text>'repoints it — keeping its id and creation date, recapturing context and the line for you. Nothing re-attaches automatically; a person confirms the reasoning still holds.
Anchoring is by excerpt, never by line number — line numbers rot on the next edit above them. The commit hash is recorded, but only to reconstruct history; it never decides whether an annotation still applies. Those are two different questions with two different mechanisms.
Local writes change the checkout you are already reviewing. Served writes never touch a replica or push a default branch: they create an exact annotation on a deterministic branch and return only after its pull request exists. Static publications remain immutable and read-only.
Three ways to run it
Pick one. Each is a place to stop, not a step you have to take, and moving
between them is not a migration — all three read the same .koment/ in git,
so there is nothing to export, import or back up.
Several repositories
One deployment serves many. Identity is assigned independently of provider path, and every refresh resolves a branch to one immutable commit before replacing a repository's active snapshot:
The service starts only when a non-loopback listener has either trusted-proxy identity or scoped bearer credentials. Private repositories and reviewed writes also require a GitHub token. The Helm chart documentation shows the secret formats and boundary.
Local commands need none of this configuration — koment finds the owning checkout by walking up from the working directory.
Kubernetes
koment publishes an OCI Helm chart to oci://ghcr.io/koment-dev/charts/koment:
The application port authenticates source, rationale, UI and MCP; only liveness
and readiness are public. Metrics use a separate listener so an ingress cannot
accidentally expose them with application authentication. The chart includes a
Grafana dashboard, ServiceMonitor, hardened pod defaults, optional NetworkPolicy
and disruption controls, and a digest-pinned helm test probe.
Configuration
Every flag can be set from the environment. --flag-name becomes
KOMENT_FLAG_NAME, and an explicit flag always wins.
Git is the only authoritative record. Local reads resolve the YAML directly against the working tree; disposable read models cannot restore or overwrite Git.
koment <command> --help lists every flag alongside its variable.
Work where the code lives
The reference VS Code extension starts koment lsp,
renders annotation bodies as virtual inline text, reports drift and prohibited
comments as diagnostics, and adds native add, reanchor, convert and explicit
acknowledgement actions. The prose is never inserted into the source buffer.
Every release attaches a signed VSIX and publishes the same artifact to the VS
Code Marketplace and Open VSX.
Other editors can use the standard hover, diagnostics, code-lens, code-action
and execute-command surface from koment lsp without reimplementing storage or
anchoring.
Claude Code can install the repository's own project-scoped marketplace plugin:
It bundles writable MCP configuration, injects the strict procedure at session
start and runs the policy gate before Claude can finish a turn. Install a
released koment binary and run koment agents install in the repository first.
OpenCode ships a parallel plugin at
integrations/agent-plugins/opencode/.
Add @koment/opencode-koment to the plugin array in opencode.json; OpenCode
installs it at startup. It requires the released koment binary on PATH,
denies ordinary explanatory comment intent and runs the policy gate on session
end. ADR 0144 records the package and generated-adapter boundary.
Codex ships the same policy surface as a local marketplace at
integrations/agent-plugins/codex/.
Install that checkout path with codex plugin marketplace add, then run
codex plugin add koment@koment-dev. The release workflow also produces a
signed archive. The plugin provides writable MCP tools, a standing skill and
trusted lifecycle hooks. ADR 0151 records the package boundary.
Give it to your agents
The generated repository adapters give agents a strict procedure and configure the writable stdio server. It has three read tools:
koment_get(file, repository?)— annotations for the file an agent is about to editkoment_search(query, repository?)— find reasoning by topic; omittingrepositorysearches all of themkoment_repositories()— what this deployment serves, with counts
Write mode adds four tools:
koment_add— create agent-attributed rationalekoment_reanchor— explicitly move an existing anchorkoment_convert_comment— record a comment as rationale, then remove itkoment_acknowledge_comment— retain an exceptional comment only after an explicit acknowledgement
Those four mutation tools operate on a local checkout. The authenticated served
MCP surface exposes koment_add and returns the deterministic branch, commit and
pull-request URL; source-mutating conversion and reanchor stay local so the
service cannot overwrite an agent's separate worktree.
Every annotation arrives with its resolution status and its repository, so a
stale one is never presented as current and a result is never detached from its
scope. When a path exists in several repositories koment_get refuses and
names the candidates rather than guessing.
Publish it
Your reviewers are not going to install anything. Give them a URL: one workflow
file renders every annotation to static HTML plus annotations.json and
search.json, then puts the atomic snapshot on GitHub Pages with no server,
database or authentication to design.
Every page names the commit it was rendered from, so a snapshot can never pass
for the current tree. koment check in the same workflow means a build that
would publish drift fails first.
The whole workflow, ready to copy →
A site renders your source as well as your annotations, so publishing one from a private repository publishes that source. Grouped publications render one snapshot per repository and connect them through the ordinary repository switcher; there is no selector landing page.
Documentation
- Publishing — the copy-paste workflow, and moving to a served instance later
- Contributor setup — establish a verified development checkout
- Getting started · Writing good annotations · CLI reference · CI
What koment is not
- Not general project documentation. koment holds knowledge bound to a place in the code; broad project guidance belongs in the documentation system your team already uses.
- Not a memory system. A consolidating store paraphrases, merges and eventually forgets. koment is a record, not a belief.
- Not line-precise. Anchors are snippets.
Prior art
Codetations / Magic Markup is the closest existing work — document-external annotations with LLM re-anchoring. The anchoring problem dates to Microsoft Research, 2001 and is still unsolved in the general case. The UI owes its shape to konflate, which makes an invisible layer visible for Flux the way koment tries to for rationale.
License
AGPL-3.0-or-later is the open-source grant for the repository except
integrations/editors/zed/. That extension code alone is
GPL-3.0-or-later so Zed may build and
distribute it through its registry; the koment binary it starts remains AGPL.
Both license files are verbatim texts so automated scanners identify them
correctly. ADR 0145
records the narrow exception.
The complete corresponding source is this repository, https://github.com/koment-dev/koment, which satisfies the AGPL §13 obligation for anyone interacting with a koment server over a network.
Commercial licences are available on request for organisations whose policy excludes AGPL, or that want warranty or indemnification — write to [email protected].
Releases ≤ v0.6.0 were distributed under the MIT licence and remain MIT in
perpetuity. The last MIT-tagged source may be forked from
v0.6.0 under those terms
indefinitely. The decision is recorded in ADR 0117.
Does using koment make my code AGPL? No. koment is a tool; annotations it writes are data, not derivative works of the tool. The same legal class applies as compiling a program with GCC: the tool's licence governs the tool, not what you build with it. This is the intent of every OSI-approved AGPL deployment that processes external input; if your organisation's counsel disagrees, the commercial licence resolves it.
來源:README.md,提交 c000b74
工具
0版本歷史
1- v3.2.0最新Sep 16, 2026
評分
已滿足適用檢查項的 50%
該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。
- 近 30 天內可連通25 分
請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。
- 已宣告認證方式10 分
請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。
- 已列出工具15 分
請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。
- 描述必需15 分
- 圖示10 分
- 文件15 分
- 授權條款10 分