mnote/.codex/reasonix-tasks/results/batch-i-worker-c-acp-review-tail.md

Batch I Worker C：7-15 / 7-12 后续拆分审查

创建时间：2026-06-15

审查依据：7-15 步骤 15-17、7-12 Phase B-F 的已完成度

---

1. 7-15 Steps 15-17 状态判断

当前完成度

Step	名称	状态	说明
1-14	ACP 核心实现	✅ 全部完成	acp_client.rs、acp_session_manager.rs、acp_runtime.rs、acp_bridge.rs、reasonix-acp-wrapper.mjs、profile 扩展、前端下拉、e2e 验证
15	压力测试	❌ 未开始	多会话并发稳定性
16	退役旧 HTTP proxy	🟡 部分开始	默认已切 ACP，但 hermes_client.rs 内的 HTTP proxy 兼容分支仍存在
17	基准测试	❌ 未开始	Reasonix 缓存收益量化

结论：Steps 15-17 应拆分为独立 checklist

理由：

1. 性质不同 — Step 15（压力测试）和 Step 17（基准测试）是验证/度量任务，不是架构实现。Step 16（清理）是维护性工作。它们与 7-15 的核心目标（ACP 抽象层实现）没有结构性依赖。

2. 完成标准不同 — 压力测试可能需要多轮迭代（发现瓶颈→修复→再测），基准测试可能发现需要缓存策略调整，退役清理需要确认所有 profile 都 migrate 完。这些都不是"一个 step done 就进入下一步"的线性模式。

3. 已开始的部分 Step 16 不够干净 — 代码中 configured_upstream_for_profile() 的 #[deprecated] 因 warning 太多被移除，表明清理依赖范围广、风险高，需要独立计划。

4. 当前 7-15 文档混杂实现 + 验证 — 读文档的人会觉得 7-15 处于"未完成"状态，但实际上架构核心已经完成并在生产运行。

建议拆分方案

将 Steps 15-17 独立为新文件 7-28-acp-runtime-stabilization-and-cleanup-v1.md，在 design/07-ai/process/ 下：

• P0：Step 16 残余 — 完成 configured_upstream_for_profile() HTTP proxy 分支的退役
• P1：Step 15 — 压力测试，重点是 ACP 子进程生命周期管理
• P2：Step 17 — 基准测试，缓存命中率对比表格

---

2. 7-12 Phase B-F 被覆盖状态

Phase B：Manifest 合同收口

条目	7-12 描述	当前代码状态	覆盖评估
B-1	manifest 输出完整 inputSchema/outputSchema/annotations/availability	✅ manifest.rs 已有完整 annotations、inputSchema、parameters	已覆盖。每个工具包含 annotations.readonly/destructive/idempotent/requiresApproval/approvalMode/runtimeOwner/writeOwner/selectionEffect
B-2	profile toggle、capability、scope 共同影响 manifest	🟡 部分	capabilityScope 已在 manifest 中，但 profile-level toggle 未动态反映到 availability.enabled 字段
B-3	manifest 可直接转换为 Hermes/model tools	✅ 前端 SSR 直接消费 manifest 作为工具列表	已覆盖。manifest 结构已与 Hermes 兼容
B-4	禁用工具在 manifest、UI、执行拦截三处一致	🟡 部分	执行拦截通过 capabilityScope + 后端 ensure_markdown_changed_blocks_within_allowed 存在，但 UI 侧 toggle 反映需验证

结论： Phase B 大部分被当前代码覆盖。B-2 和 B-4 的核心缺口是 profile-level dynamic availability，而不是 manifest 内容。

Phase C：block-edit-workflow 改造成 router

条目	7-12 描述	当前代码状态	覆盖评估
C-1	route 命名和返回 schema 改为 mnote.page_ai_command_route.v1	❌ 未实施	page_ai_workflow.rs 仍在用内部 MarkdownPlan 对象，没有公开的 PageAICommandRouter route
C-2	本地规则只输出 recommendedToolCall	🟡 间接覆盖	page_ai_workflow.rs 中的 direct_block_edit_operations 已退役，改走 model → search/replace → doc_markdown_edit 路径
C-3	低风险 yolo shortcut 走共享 mnote tool executor	✅ 当前路径	doc_markdown_edit 直接调用 Rust tool executor
C-4	非低风险任务发起 Hermes run with tool hint	✅ ACP integration	acp_runtime.rs + acp_session_manager.rs 提供完整的 Hermes/Reasonix run 路径
C-5	删除"模型 fallback 后再 Hermes agent run"重复链路	🟡 需确认	page_ai_workflow.rs 中的 call_block_edit_model → extract_markdown_plan 链路仍然存在，但已改为直接走 doc_markdown_edit 不回落

结论： Phase C 的架构目标（agent-native 编辑 > mnote block ops）已通过 ACP + local-first 口径实现，但正式的 PageAICommandRouter 模块从未实现。不需要再实现它——当前架构已满足 7-12 的安全合同目标。

Phase D：Review Session

条目	7-12 描述	当前代码状态	覆盖评估
D-1	schema 和状态机边界	✅ 文档已定义	设计文档 §5.5 已完成
D-2	plan_update/apply_block_ops dryRun=true 返回 review-compatible draft	🟡 部分	dryRun 支持存在且返回 diff/warnings/risk/blocked，但输出格式不是 review session schema
D-3	UI 展示 diff/warnings/risk/blocked	❌ 冻结	Phase C 仍冻结，不实施
D-4	accept/reject/retry/abort	❌ 冻结	同上
D-5	stale revision 阻断	✅ 部分	ensure_markdown_changed_blocks_within_allowed + revision 检查

结论： 符合 7-12 §0 的指示——"Phase C UI 仍冻结，不实施流式 apply 或新的审阅 UI"。本报告不建议本轮实现。

Phase E：状态与事件统一

条目	7-12 描述	覆盖评估
E-1	direct shortcut 和 Hermes run 统一 tool event 形态	✅ ACP session/update 作为统一事件源
E-2	页面 AI 面板按 runId/toolCallId/reviewSessionId 聚合	🟡 前端已支持 runId/toolCallId，reviewSessionId 未用
E-3	abort 不留下半写入正文	✅ ACP session/cancel + 本地回滚
E-4	刷新后未提交 review session 不自动写入	✅ 不适用（review session 未实现）

Phase F：验收 Smoke

条目	7-12 描述	覆盖评估
F-1	低歧义替换 <1s 且 tool audit	🟡 功能存在，具体延迟需要基准测试（Step 17）
F-2	复杂改写进 Hermes run，先 dry-run/review	✅ ACP 路径支持
F-3	selection 外写入 blocked	✅ hermes_tools_markdown_edit_rejects_selection_out_of_scope 测试 pass
F-4	禁用工具一致	🟡 后端拦截存在，manifest 动态 toggle 待完善
F-5	旧 revision accept → stale	❌ review session 未实现，此场景不存在

---

3. Phase C Review Mode 冻结确认

确认冻结。 符合 7-12 §0 的 2026-05-18 更新：

PageAIReviewSession 只定义 Phase C 的安全合同和状态机边界；当前 Phase C 仍冻结，不实施流式 apply 或新的审阅 UI

由于 review mode UI 涉及：

1. 新的前端组件（diff 面板、accept/reject/retry/abort 按钮）
2. 新的后端 session 持久化路径
3. 与 ACP session 的生命周期整合（review session 超时、刷新恢复）
4. thought.delta / usage.updated 的可视化渲染

这些都不在本轮范围内。所有 review-compatible 的后端数据结构（dryRun、changedBlocks、audit）已准备就绪，仅差 UI 整合。

---

4. 下一批 P0/P1/P2 优先级

P0（本轮必须完成）

编号	工作	对应	风险
P0-1	完成 configured_upstream_for_profile() 的 HTTP proxy 清理	7-15 Step 16 残余	低。当前默认已切 ACP，但 hermes_client.rs 中 ~500 行 HTTP proxy 路径仍有调用者确认
P0-2	确认 page_ai_workflow.rs 在所有 profile 下不走 block_edit fallback	7-12 C-5	中。当前 workflow 调 call_block_edit_model → extract_markdown_plan → doc_markdown_edit，但少部分 code path 可能还有残留的 apply_block_ops
P0-3	7-15 拆分为「核心实现」(done) + 「稳定化清单」(new)	本审查结论	低。只改设计文档

P1（紧接 P0 后）

编号	工作	对应	风险
P1-1	压力测试：多会话并发、ACP 子进程异常恢复	7-15 Step 15	中。需要同时管理 3+ 会话时 Hermes/Reasonix 子进程状态
P1-2	动态 tool availability per profile（manifest 的 enabled 字段）	7-12 B-2/B-4	中低。影响 tool toggle/audit 一致性
P1-3	plan_update dryRun 输出适配 review session schema	7-12 D-2	低。后端数据结构对齐

P2（可并行但非阻塞）

编号	工作	对应	风险
P2-1	基准测试：Reasonix cache hit rate vs Hermes	7-15 Step 17	低。纯度量，不涉及代码变更
P2-2	7-12 更新状态：标记 Phase B 已完成项、更新口径	设计治理	低
P2-3	复杂块 GFM 解析 fallback 覆盖（list/code block/blockquote）	7-27 §5.3	低。影响 full_content 块类型推断
P2-4	页面 AI thought.delta 可视化	7-15 Step 11 note	低。当前预期行为是不显示 thought

---

5. 验收证据

• cargo test -p mnote-web markdown_edit -- --test-threads=1 → 16 pass
• cargo test -p mnote-web hermes_tools_manifest_describes_markdown_edit_write_contract -- --test-threads=1 → 1 pass
• git diff --check → 无 whitespace 错误
• 本文件已写入 .codex/reasonix-tasks/results/batch-i-worker-c-acp-review-tail.md