Hi — really appreciate detritus, it's become a core part of my Claude Code setup. While poking around I ran a quick dependency / govulncheck pass and noticed a couple of things I thought might be worth surfacing. All low-stakes, and entirely your call on whether any of it is worth doing — mostly just flagging in case it's useful.
One concrete thing (security hygiene):
govulncheck ./... flags a handful of reachable stdlib CVEs (crypto/tls, crypto/x509, net, net/textproto) because the build floats on the installed Go — there's no toolchain directive in go.mod, and the go 1.25.0 line predates the patched releases. Pinning toolchain go1.25.12 (or the current latest 1.25.x) clears them. One line, module-scoped, no code change.
A few optional ideas, no pressure on any of them:
modelcontextprotocol/go-sdk v1.4.0 → v1.6.1 looks like a clean bump for a stdio server — it advances the negotiated protocol version (2025-06-18 → 2025-11-25), returns arg-validation failures as tool results instead of JSON-RPC errors, and picks up a few race/robustness fixes. The bulk of the changelog is OAuth / cross-origin / SSE work that doesn't apply to the stdio transport, and the one behavior change (SetError now preserves Content) doesn't affect detritus since it builds CallToolResult directly.- The tool handlers currently return
nil for the structured-output slot. Emitting structuredContent for the machine-usable tools (kb_search, code_graph, code_map) and adding readOnlyHint annotations to the read-only tools could let clients consume results without re-parsing prose. Both are already supported at the current SDK version, so no bump needed for those.
Happy to open a PR for just the toolchain pin + SDK bump if you'd like — it's the smallest, safest slice and I've verified it builds/tests clean locally. And totally fine to close this if it's not a direction you want to take things.
🤖 Generated with Claude Code
Hi — really appreciate detritus, it's become a core part of my Claude Code setup. While poking around I ran a quick dependency /
govulncheckpass and noticed a couple of things I thought might be worth surfacing. All low-stakes, and entirely your call on whether any of it is worth doing — mostly just flagging in case it's useful.One concrete thing (security hygiene):
govulncheck ./...flags a handful of reachable stdlib CVEs (crypto/tls, crypto/x509, net, net/textproto) because the build floats on the installed Go — there's notoolchaindirective ingo.mod, and thego 1.25.0line predates the patched releases. Pinningtoolchain go1.25.12(or the current latest 1.25.x) clears them. One line, module-scoped, no code change.A few optional ideas, no pressure on any of them:
modelcontextprotocol/go-sdkv1.4.0 → v1.6.1 looks like a clean bump for a stdio server — it advances the negotiated protocol version (2025-06-18→2025-11-25), returns arg-validation failures as tool results instead of JSON-RPC errors, and picks up a few race/robustness fixes. The bulk of the changelog is OAuth / cross-origin / SSE work that doesn't apply to the stdio transport, and the one behavior change (SetErrornow preserves Content) doesn't affect detritus since it buildsCallToolResultdirectly.nilfor the structured-output slot. EmittingstructuredContentfor the machine-usable tools (kb_search,code_graph,code_map) and addingreadOnlyHintannotations to the read-only tools could let clients consume results without re-parsing prose. Both are already supported at the current SDK version, so no bump needed for those.Happy to open a PR for just the toolchain pin + SDK bump if you'd like — it's the smallest, safest slice and I've verified it builds/tests clean locally. And totally fine to close this if it's not a direction you want to take things.
🤖 Generated with Claude Code