feat(serve): agent 原生查询面——管线写码中途终于能被问一句话 (#54 #58) - #195
Open
2233admin wants to merge 5 commits into
Open
Conversation
`code-intel serve --mcp`：stdio MCP server，把已提交 run 投影成六个可调工具。 #58 的审计结论是，管线在写码时隐形是结构性的，不是采纳惰性：每个 agent 面 都是"读/审"形状或事后门，没有任何一个在写的过程中帮上忙。它的提案 1（SKILL 写路径触发词）与提案 2（`change impact --staleness advisory`）已先后落地， 剩下提案 3——agent 引过来之后，没有一句话能问的接口。本次补上这一块。 工具： - get_gate_verdict 权威 run 的门禁结论 + 第一条失败规则 + 最小重跑命令 - get_facts 按 artifact type / schema / 子串查已验证事实 - get_evidence 一条 finding 的证据链：产物、sha256、记录时的 snapshot - get_audit_status 各科室结论、评分、覆盖 - get_change_impact 改这些文件波及谁、先跑哪些测试（默认 stale-advisory） - plan_structural_edit ast-grep 结构改写预览 只读边界是机械的，不是口头的： - 门禁判定照旧只走 CLI 与 CI 路径。查询面被 prompt injection 说服也改不了结论。 - 唯一会执行东西的 plan_structural_edit，在跑之前拿注册表核对自己 capability 的 allowedEffects，一旦出现 repo_mutation 就拒绝执行——这是 ai-safety-002 教训的架构化，有测试为证。 - 路径参数复用 change_impact / evidence_query 的既有请求类型：JSON 进来的路径 和 --changed 打进来的走同一道越界闸，不新开一个更松的解析器。 - 参数集闭合校验先于任何 IO：schema 里的 additionalProperties:false 只是给 规矩客户端的提示，不是闸门。 诚实位： - 工具拒答走 isError 结果，不走 JSON-RPC error。"还没跑过 run"是答案，不是 传输故障；混淆二者会把能用的工具训成"看起来老是坏的"。 - 没有 audit 产物时报 unavailable 并说明原因，不静默当成审计通过。 - 证据链查不到时报 unbacked，并声明这只表示没有已提交产物提到它，不表示 该 finding 为假。 README 与 SKILL.md 改为主推查询面，全量 --mode normal 降为深检模式（#54 出口 条件 3）。仓库 .mcp.json 注册本 server，--repo 显式钉住：worktree 目录名不是 run commit 发布时用的仓名。 路由拆进 routes/serve_routes.rs，与 edit_routes / run_routes 同一约定—— routes/mod.rs 已逼近本仓自己的巨石阈值，新命令不该再往里堆。 验证：cargo test 全绿（56 个 suite）、cargo fmt --check 干净、clippy 对新模块 零告警、权威 self-scan 在本分支 completed/green（4657 anchors verified， 0 dropped，failing_rules 0）。真机 stdio 会话核实六个工具全部作答：脏工作树下 get_change_impact 返回 stale-advisory 并同时给出 recorded/current 两个 snapshot identity，requireCurrent:true 仍按原语义 fail-closed。 Refs #54 #58
|
🔒 Repowise is not analyzing this repository The PR bot is free on public repositories. This one is private, which needs a Pro plan. |
|
Warning Review limit reached
Next review available in: 7 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (21)
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe CLI now provides ChangesMCP server integration
Estimated code review effort: 4 (Complex) | ~60 minutes Sequence Diagram(s)sequenceDiagram
participant MCPClient
participant CodeIntelServe
participant ToolRegistry
participant EvidenceHandlers
MCPClient->>CodeIntelServe: Send JSON-RPC tools/call request
CodeIntelServe->>ToolRegistry: Validate the requested tool
ToolRegistry-->>CodeIntelServe: Return registered tool metadata
CodeIntelServe->>EvidenceHandlers: Dispatch validated arguments
EvidenceHandlers-->>CodeIntelServe: Return query or planning result
CodeIntelServe-->>MCPClient: Return structured MCP response
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
📝 Generate docstrings
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Code Intel change risk
Top signals
revspec: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
crates/code-intel-cli/src/mcp_serve/handlers.rs (1)
300-323: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valuePreserve the reason the plan could not be read.
Lines 303-305 chain
.ok()over the artifact lookup, the file read, and the JSON parse. All three failures collapse into the sameNone. The error at Lines 317-323 then reports "edit plan produced no artifact" even when the artifact exists but is unreadable or malformed.Keep the failure reason so an operator can tell a missing artifact from a corrupt one.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@crates/code-intel-cli/src/mcp_serve/handlers.rs` around lines 300 - 323, Update the plan extraction before the cleanup and match in the surrounding handler so artifact lookup, file reading, and JSON parsing preserve distinct failure reasons instead of collapsing through .ok() into None. Keep successful plans returning the existing response, but make the error branch report whether the artifact is missing, unreadable, or malformed, including the underlying error details where available.crates/code-intel-cli/src/mcp_serve/tools.rs (1)
128-144: 🚀 Performance & Scalability | 🔵 Trivial | 💤 Low valueConsider an upper bound on
changed.
pathsinplan_structural_editdeclaresmaxItems: 64.changeddeclares onlyminItems: 1. The server-siderequired_string_arrayalso applies no upper bound. A client can therefore submit a very large array, andexecute_stale_advisorytraverses the reverse import graph for every entry. An explicitmaxItemsmakes the two array arguments consistent and bounds the work.♻️ Proposed bound
"changed": { "type": "array", "items": {"type": "string"}, "minItems": 1, + "maxItems": 256, "description": "Repository-relative paths you are changing, e.g. src/auth/token.rs." },🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@crates/code-intel-cli/src/mcp_serve/tools.rs` around lines 128 - 144, Update the changed array schema in the tool definition to include the same maxItems: 64 bound used by paths in plan_structural_edit, and update the server-side required_string_array validation for changed to enforce that upper limit before execute_stale_advisory processes the entries.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.mcp.json:
- Line 11: Update the code-intel MCP descriptions in .mcp.json at line 11,
README.md at line 547, and skills/code-intel-pipeline/SKILL.md at lines 119-123
to use tool-specific data-source and freshness wording. Keep committed-evidence
language for tools that read committed projections, but explicitly state that
get_change_impact compares committed impact with --repo-path and
plan_structural_edit scans the current checkout; revise all three sites
consistently.
In `@crates/code-intel-cli/src/mcp_serve/handlers.rs`:
- Around line 434-443: Update optional_limit to validate parsed limits against
the shared 1..=100 constraint before converting to usize, rejecting zero, values
above the maximum, and values that cannot safely fit in usize. Preserve
DEFAULT_LIMIT for missing or null values and retain the existing type errors for
non-number inputs so get_facts, get_evidence, and evidence_chain all receive the
same validated range.
In `@crates/code-intel-cli/src/mcp_serve/mod.rs`:
- Line 41: Update SUPPORTED_PROTOCOL_VERSIONS to avoid advertising 2025-03-26
unless handle_line is extended to parse and dispatch top-level JSON-RPC batches
as JSONRPCBatchRequest with responses. Prefer narrowing the advertised revisions
to those fully supported by the current framing, preserving existing
single-object handling.
---
Nitpick comments:
In `@crates/code-intel-cli/src/mcp_serve/handlers.rs`:
- Around line 300-323: Update the plan extraction before the cleanup and match
in the surrounding handler so artifact lookup, file reading, and JSON parsing
preserve distinct failure reasons instead of collapsing through .ok() into None.
Keep successful plans returning the existing response, but make the error branch
report whether the artifact is missing, unreadable, or malformed, including the
underlying error details where available.
In `@crates/code-intel-cli/src/mcp_serve/tools.rs`:
- Around line 128-144: Update the changed array schema in the tool definition to
include the same maxItems: 64 bound used by paths in plan_structural_edit, and
update the server-side required_string_array validation for changed to enforce
that upper limit before execute_stale_advisory processes the entries.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 86a58c56-33b3-4364-82b8-2a7084b059a3
📒 Files selected for processing (18)
.mcp.jsonCHANGELOG.mdREADME.mdcrates/code-intel-cli/src/change_impact.rscrates/code-intel-cli/src/cli/command_catalog/mod.rscrates/code-intel-cli/src/cli/command_catalog/routes/mod.rscrates/code-intel-cli/src/cli/command_catalog/routes/serve_routes.rscrates/code-intel-cli/src/cli/command_catalog/tests.rscrates/code-intel-cli/src/cli/legacy.rscrates/code-intel-cli/src/evidence_query.rscrates/code-intel-cli/src/main.rscrates/code-intel-cli/src/mcp_serve/handlers.rscrates/code-intel-cli/src/mcp_serve/mod.rscrates/code-intel-cli/src/mcp_serve/tests.rscrates/code-intel-cli/src/mcp_serve/tools.rscrates/code-intel-cli/tests/fixtures/cli-head-parity.v2.jsoncrates/code-intel-cli/tests/mcp_serve.rsskills/code-intel-pipeline/SKILL.md
CodeRabbit 在 #195 上报的四条,逐条核实全部成立。 1. `optional_limit` 不执行自己声明的 1..=100(真 bug) `get_facts` 的 limit 经 `EvidenceQueryRequest::new` 有界,`get_evidence` 直接 吃原值。`limit: 0` 让 `evidence_chain` 在第一条匹配上就 `links.len() == limit` 成立、break,于是返回 status "unbacked"——这是在断言"没有任何已提交产物提到 该标识符",而提到它的产物就摆在那里。诚实位被一个未校验的参数变成了谎报。 `as usize` 也未经检查:32 位目标上超 u32::MAX 会截断,被拒的值反而通过。 修法是把界放进 `optional_limit`,比较在 cast 之前对 u64 做;上界从 `evidence_query::MAX_LIMIT` 读,不再各写一份 100。只有一个调用方遵守的界不是界。 2. 只宣称本 transport 真能实现的 MCP 版本 原先 SUPPORTED_PROTOCOL_VERSIONS 含 2025-03-26 与 2024-11-05,这两版要求服务端 接受 JSON-RPC 批量(顶层数组)。本 transport 一行一条消息,没有批量派发——协商到 这些版本的客户端发批量后会永远等不到回应。2025-06-18 移除了批量,正是本框架能 诚实声明的唯一一版。 3. 批量请求显式拒绝,不再静默丢 数组没有自己的 `id`,原先会落进 notification 分支被丢掉——客户端挂死。现在回 -32600 并说明原因。即使版本已收窄,走错路的批量也该听见拒绝,而不是沉默。 4. 保留失败原因,不再三合一 `plan_structural_edit` 读回计划时,产物查找 / 文件读取 / JSON 解析三条失败路径 都经 `.ok()` 塌成同一个 None,于是"产物损坏"被报成"没产出产物"。拆成 `read_plan_artifact`,各自带各自的原因。 5. 数据来源逐工具写清 四个工具是已提交 run 的投影,但 `get_change_impact` 是"已提交 import 图 × 当前 --repo-path",`plan_structural_edit` 扫的是当前工作树。原先 .mcp.json / README / SKILL.md 一律写成"来自已提交 run",对后两个是错的。按工具分列。 验证:新增 3 个测试(版本面收窄、批量显式拒绝、两个 limit 调用方共享同一道界, 含 0/101 拒绝与 1/100/缺省放行)。cargo test 全绿(56 suite)、fmt 干净、clippy 对本模块零告警、权威 self-scan completed/green(4661 anchors verified、0 dropped)。 真机核实:limit 0 与 101 均被拒并给出 1..=100,limit 2 正常返回 2 条并正确标 truncated;批量收到 -32600;客户端请求 2025-03-26 被换成 2025-06-18。 Refs #54 #58
# Conflicts: # crates/code-intel-cli/src/cli/command_catalog/mod.rs
main 落了 v0.7.0-beta.6 与三道新门(#190、#197/#199、#198),四处要处理: 1. `command_catalog/mod.rs` 导入表冲突 两边各往同一个 `use crate::{...}` 里加了一个模块。取并集: `invocation_identity` 与 `mcp_serve` 并存,按字母序。 2. CHANGELOG 被静默并进了 beta.6 我的条目原在 `[Unreleased]`,#196 在其上切了 `[0.7.0-beta.6]` 发版段,git 把两侧文本合成一处——结果是本 PR 尚未合并的特性出现在已发布版本的清单里。 这是内容层面的错,不是文本冲突,git 不会报。重新起 `[Unreleased]` 段并把条目 移回去,顺带补上 review 轮次里落的两条(MCP 版本面收窄到 2025-06-18、数据来源 按工具分列)。 3. `declared_pins` 门(#190)红:声明摘要过期 新增文件改变了扫描面。`repin --repo . --write` 重同步,复核 `clean: true` `filesChanged: 0` `passes: 1`。按 #129 的教训,repin 之后重跑全套而不是只信 它自己的 clean 位。 4. `env_contract` 门(#190)红:测试直接 spawn 二进制 `tests/mcp_serve.rs` 自己 `Command::new(binary())` 并手动 `env_remove` 两个 变量——正是这道门存在的理由:手挑的两个之外,`PIPELINE_VARS` 里其余变量仍会 从开发者 shell 漏进被测子进程,把测试指向真实安装,然后默认分支从未被测到。 改走 `common::cli()`,清单与二进制声明的同一份。 验证:cargo test 59 个 suite 全绿(比合并前多 3 个,来自 main 的新门)、 fmt 干净、repin clean、权威 self-scan completed/green(4702 anchors verified、 0 dropped、0 approximate)。 Refs #54 #58
你在 bc4b5d5 里也把 main 并了进来。两个 merge 的父提交完全相同,只是冲突解法 不同;这里合并而不是 force-push,你那次提交原样留在历史里。 bc4b5d5 的解法会让 main 上刚落的两道新门变红,本次并入时按本地解法定稿: - `tests/mcp_serve.rs` 走 `common::cli()` 而不是 `Command::new(binary())`。 env 洁净门(#190)拦的就是这个:手挑几个变量 `env_remove` 之外, `PIPELINE_VARS` 里其余的仍会从开发者 shell 漏进被测子进程。 - `orchestration/internalization/*.json` 已 repin。声明摘要门(#190)要求 扫描面变了就重同步。 - CHANGELOG 条目回到 `[Unreleased]`。git 把它并进了 `[0.7.0-beta.6]` 发版段, 内容上是错的——本 PR 还没合,不该出现在已发布版本的清单里,而这类错 git 不会报冲突。 验证:cargo test 59 个 suite 全绿、fmt 干净、repin clean/filesChanged 0。 Refs #54 #58
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
为什么
#58 的审计结论是：管线在写码时隐形是结构性的，不是采纳惰性——每个 agent 面都是"读/审"形状或事后门，没有一个在写的过程中帮上忙。
先说一个发现：#58 的票过期了。核实现场后，六条提案里有两条已经悄悄落地、票没更新：
skills/code-intel-pipeline/SKILL.mdfrontmatter 已含 "before implementing, refactoring, or fixing code"、"mid-edit question is what breaks if these files change"change impact --staleness advisory）已做 —change_impact.rs里Staleness::Current | Advisory已在解析剩下的是提案 3：触发词把 agent 引过来了，引过来发现没有一句话能问的接口。只能跑全量自扫或读产物文件。
.mcp.json里注册的只有 repowise —— #58 当初点名的"第三方占了本该自己占的位"，是仓里写死的配置。本 PR 补这一块，同时兑现 #54。
做了什么
code-intel serve --mcp—— stdio MCP server，把已提交 run 投影成六个可调工具。get_gate_verdictget_factsget_evidenceget_audit_statusget_change_impactplan_structural_editrepositoryMutation=false前四个是 #54 规定的只读面，后两个是 #58 提案 3 追加的写辅助投影。
只读边界是机械的，不是口头的
plan_structural_edit，在跑之前拿注册表核对自己 capability 的allowedEffects，一旦出现repo_mutation拒绝执行——这是 ai-safety-002 教训的架构化，有测试为证。change_impact/evidence_query的既有请求类型：JSON 进来的路径和--changed打进来的走同一道越界闸，不新开一个更松的解析器。5 条穿越路径逐条测过。additionalProperties:false只是给规矩客户端的提示，不是闸门。诚实位
isError结果，不走 JSON-RPC error。"还没跑过 run"是答案，不是传输故障；混淆二者会把能用的工具训成"看起来老是坏的"。unavailable并说明原因，不静默当成审计通过。unbacked，并声明这只表示没有已提交产物提到它，不表示该 finding 为假。真机核实
脏工作树下问
get_change_impact—— 这正是 CLI 会 fail-closed 的场景，也是 #58 标 critical 的那个洞：同一把工具带
requireCurrent: true仍按原语义拒绝，报出 recorded/current 两个 identity。两边语义都在。get_gate_verdict在真 run 上：status: green、failingRuleCount: 0、evidenceRef.sha256带着、rerun 命令可直接粘贴（剥了 Windows\\?\前缀）。plan_structural_edit真调起 ast-grep 0.42.3，出匹配清单，repositoryMutation: false，一个字节没写。验证
cargo test：56 个 suite 全绿cargo fmt --all --check：干净cargo clippy --all-targets：新模块零告警--mode normal）在本分支：outcome: completed、hospitaltriage.status: green、failing_rules: []、4657 anchors verified / 0 dropped顺带
--mode normal降为深检模式（[evidence-kernel] T9 agent-native 查询面:code-intel serve --mcp(只读) #54 出口条件 3）.mcp.json注册本 server。--repo显式钉住 —— worktree 目录名不是run commit发布时用的仓名，不钉就会去查错仓的 runroutes/serve_routes.rs，与edit_routes/run_routes同一约定：routes/mod.rs已逼近本仓自己的巨石阈值，新命令不该再往里堆cli-head-parity.v2.json的 help 增量按既有约定更新new字节，contract id 仍是help-full.v1 -> v2不升版（"full help 记录每一条已注册路由"是同一个版本化行为，不该每加一个命令就爬一版）已知留白
get_audit_status只在 run 带diagnosis.audit产物时有内容；本仓当前的 run 不带，工具会明说Refs #54 #58