chore: 保存当前架构收口与 bug 修复快照

归档本轮 P0/P1 bug 修复、设计审查迁移、AI selection scope 收口与 stream contract 调整，并保留当前 05 主线迁移起点。
2026-05-18 17:01:35 +08:00
parent 61ee4a38a2
commit a2cb1338c8
953 changed files with 14383 additions and 211845 deletions
@@ -1,61 +0,0 @@
-# 7-16 [process][bug] mnote.doc.markdown_edit 中文归一化替换 byte index 误用 v1
-
-> 发现时间：2026-05-17
->
-> 状态：`[process]`
->
-> 关联主线：`07-ai`
->
-> 关联代码：
-> - `rust/crates/mnote-web/src/hermes_tools/doc.rs:895-956` — `search_replace`
-> - `rust/crates/mnote-web/src/hermes_tools/doc.rs:920-936` — 归一化匹配后的切片计算
-
-## 1. 问题定义
-
-`mnote.doc.markdown_edit` 的 `search_replace` 在 Level 2 “忽略首尾空白和全角 / 半角差异”分支中，先对 `norm_line` 调用 `find(&norm_search)`，得到的是 UTF-8 byte offset：
-
-```rust
-let start = norm_line.find(&norm_search).unwrap();
-let end = start + norm_search.len();
-```
-
-随后代码把 `start / end` 当成字符序号传给 `line.char_indices().nth(...)`：
-
-```rust
-&line[..line.char_indices().nth(start).map(|(i, _)| i).unwrap_or(0)]
-&line[line.char_indices().nth(end).map(|(i, _)| i).unwrap_or(line.len())..]
-```
-
-这在 ASCII 文本里不明显，但中文、中文标点、全角字符都是多字节。byte offset 不等于字符序号，最终替换范围会偏移。
-
-## 2. 影响
-
- 页面 AI 对中文正文执行 `mnote.doc.markdown_edit` 时，归一化匹配可能替换错位置。
- 本地 `.md` 文件和在线 Convex 文档共用该工具，因此两条 AI 编辑路径都会受影响。
- 如果替换结果继续写回，用户看到的正文可能被局部破坏，而不是简单失败。
-
-## 3. 复现思路
-
-构造一行中文正文，让精确匹配失败但归一化匹配命中，例如带首尾空白或全角 / 半角差异的 search：
-
-```text
-原文：第一段内容
-search： 一段
-replace：二段
-```
-
-`find()` 得到的是 byte offset；当前代码按字符序号切片后，替换边界会落到错误字符位置。
-
-## 4. 根因
-
-`str::find` 返回 byte index；`char_indices().nth(n)` 的 `n` 是第几个字符。当前实现把两种索引体系混用。
-
-## 5. 建议修复
-
- 在归一化时保留原文字符到归一化字符的 offset map。
- 或者只在同一字符串上使用 byte index，并确保切片边界来自同一个原始字符串的 `char_indices` 映射。
- 增加中文、多字节标点、全角英文 / 数字混排的 `search_replace` 单测。
-
-## 6. 状态
-
-已确认源码层缺陷，尚未修复。进入 `process` 等待实现和验证。
@@ -1,75 +0,0 @@
-# 7-17 [process][bug] mnote.doc.markdown_edit 同块多操作写回会覆盖前序修改 v1
-
-> 发现时间：2026-05-17
->
-> 状态：`[process]`
->
-> 关联主线：`07-ai`
->
-> 关联代码：
-> - `rust/crates/mnote-web/src/hermes_tools/doc.rs:779-824` — markdown 字符串层顺序执行 operations
-> - `rust/crates/mnote-web/src/hermes_tools/doc.rs:854-878` — Convex 写回重新转换成 block ops
-> - `rust/crates/mnote-web/src/hermes_tools/doc.rs:976-1008` — `build_block_ops_from_markdown_edit`
-
-## 1. 问题定义
-
-`doc_markdown_edit` 会先把所有 search/replace 顺序应用到 `md`：
-
-```rust
-match search_replace(&md, &search, &replace) {
-    Ok(new_md) => {
-        md = new_md;
-        applied += 1;
-    }
-    ...
-}
-```
-
-但在线 Convex 文档写回时没有使用这个最终 `md`。当前实现重新读取 Page Aggregate blocks，然后对每条 operation 基于原始 block 文本生成一个 replace block op：
-
-```rust
-let block_text = block.get("text").and_then(Value::as_str).unwrap_or("");
-let new_text = block_text.replacen(search, replace, 1);
-```
-
-如果两条 operation 命中同一个 block，第二条 operation 的 `new_text` 仍从原始 `block_text` 计算，会覆盖第一条 operation 的结果。
-
-## 2. 影响
-
-用户在页面 AI 中一次提出多个同段修改时，可能只保留最后一个修改。例如：
-
-```json
-[
-  { "search": "A", "replace": "B" },
-  { "search": "C", "replace": "D" }
-]
-```
-
-若 `A` 和 `C` 都在同一个 block 中，markdown 层预期最终是 `B ... D`，但写回层可能生成两个 replace block op：
-
-```text
-op1 content = 原始文本中 A -> B
-op2 content = 原始文本中 C -> D
-```
-
-最终第二次 replace 会把 block 写成只包含 `C -> D` 的版本，前一次 `A -> B` 被丢失。
-
-## 3. 根因
-
-`doc_markdown_edit` 有两套编辑结果：
-
- `md`：顺序应用 operations 后的真实 markdown 结果。
- `block_ops`：从原始 blocks 和原始 operations 重新推导出来的写回操作。
-
-Convex 写回使用的是 `block_ops`，而不是 `md`。这让“markdown 编辑主路径”在在线文档里退化成了不完整的 block ops 转换层。
-
-## 4. 建议修复
-
- 最小修复：`build_block_ops_from_markdown_edit` 先按 block 聚合 operations，并基于当前已更新文本连续计算同块最终 content。
- 更稳妥修复：以最终 `md` 作为单一结果，走 markdown -> EditorBlockDocument / page.body.save 的正式转换链，不从原始 operations 二次推导写回结果。
- 增加同一 block 多 operation 的单测和真实 Page Aggregate 回读 smoke。
- 明确部分失败是否允许写入；默认建议任一 operation 失败时不写入，除非调用方显式允许 partial apply。
-
-## 5. 状态
-
-已确认源码层缺陷，尚未修复。进入 `process` 等待实现和验证。
@@ -1,35 +0,0 @@
-# 7-18 [process][bug] AI markdown_edit 阶段状态合同漂移 v1
-
-> 发现时间：2026-05-17
->
-> 状态：`[process]`
->
-> 关联主线：`07-ai`
-
-## 1. 问题定义
-
-当前仓库的顶层协作口径仍描述 AI 侧“当前只做 Phase A，Phase B 退役 `local_rule` planner 仍未实施”，但 `design/07-ai/process/7-14-online-local-ai-markdown-editing-convergence-v1.md` 与源码已经把 `mnote.doc.markdown_edit` 推到实际运行链路。
-
-这造成阶段合同漂移：文档与实现同时在表达“仍处 Phase A”和“Phase A / B 已开始切主”两种状态。
-
-## 2. 影响
-
- 后续开发者无法判断 `page_ai_workflow` 是否应继续保留 `local_rule` 快路径。
- AI 编辑验收标准会混乱：到底验 `apply_block_ops`，还是验 `markdown_edit` 回读一致性。
- 新功能容易继续堆到过渡路径，而不是收敛到正式工具合同。
-
-## 3. 证据
-
- `rust/crates/mnote-web/src/routes/page_ai_workflow.rs` 已直接调用 `doc::doc_markdown_edit`。
- `design/07-ai/process/7-14-online-local-ai-markdown-editing-convergence-v1.md` 已记录在线 / 本地 markdown 编辑收敛方向。
- 根目录协作口径仍强调 Phase B 退役 `local_rule` planner 属于后续项。
-
-## 4. 建议修复
-
- 明确当前真实阶段：`markdown_edit` 是否已经是页面 AI 简单编辑主路径。
- 若已切主，应把 `page_ai_workflow`、Hermes guidance、manifest 和 smoke 都同步到该口径。
- 若未切主，应限制 `markdown_edit` 的 runtime 使用面，并把设计稿状态回退为实验态。
-
-## 5. 状态
-
-已确认设计口径与源码使用状态不一致，尚未完成统一。
@@ -1,35 +0,0 @@
-# 7-19 [process][bug] Hermes 工具指导仍优先 apply_block_ops 而非 markdown_edit v1
-
-> 发现时间：2026-05-17
->
-> 状态：`[process]`
->
-> 关联主线：`07-ai`
-
-## 1. 问题定义
-
-`mnote.doc.markdown_edit` 已被设计为普通页面正文编辑的主路径，但 Hermes run 的工具指导仍要求简单正文编辑优先调用 `mnote_doc_apply_block_ops`。
-
-这导致模型策略与工具主线冲突。
-
-## 2. 证据
-
- [hermes_client.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/routes/hermes_client.rs:2351) 构造工具指导。
- [hermes_client.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/routes/hermes_client.rs:2357) 要求上下文足够时直接调用 `mnote_doc_apply_block_ops`。
- [hermes_client.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/routes/hermes_client.rs:2360) 明确“简单小段落编辑”优先用 `apply_block_ops`。
-
-## 3. 影响
-
- Hermes 与 page AI fast-path 会走不同编辑工具。
- markdown 级 search/replace 的收敛设计无法成为唯一验收口径。
- `apply_block_ops` 的 revision / conflictDetectionKey 合同缺陷会被继续放大。
-
-## 4. 建议修复
-
- 将普通正文 search/replace、局部段落替换、全文 markdown 替换统一引导到 `mnote_doc_markdown_edit`。
- 仅在需要结构性块移动、资源块、复杂定位时才引导模型使用 `apply_block_ops` 或 `mnote.block.*`。
- 同步更新 smoke：模型生成工具调用时应优先产出 `mnote_doc_markdown_edit`。
-
-## 5. 状态
-
-已确认源码指导文本与当前设计主线不一致，尚未修复。
@@ -1,35 +0,0 @@
-# 7-20 [process][bug] page_ai_workflow 绕过 Hermes tool executor / audit / toggle v1
-
-> 发现时间：2026-05-17
->
-> 状态：`[process]`
->
-> 关联主线：`07-ai`
-
-## 1. 问题定义
-
-`/api/page-ai/block-edit-workflow` 仍是独立模型调用链：直接读取 Hermes profile、调用 chat/completions、解析模型 JSON，并直接调用 Rust 工具函数。
-
-它没有通过 `/api/hermes/tools/mnote/call` 的工具执行壳，因此绕过了 tool toggle、audit、统一幂等和统一调用追踪。
-
-## 2. 证据
-
- [page_ai_workflow.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/routes/page_ai_workflow.rs:69) 直接调用上游模型。
- [page_ai_workflow.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/routes/page_ai_workflow.rs:91) 在 route 内构造 `ToolCallInput`。
- [page_ai_workflow.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/routes/page_ai_workflow.rs:109) 直接调用 `doc::doc_markdown_edit`。
-
-## 3. 影响
-
- 关闭或限制 mnote tool 时，该 fast-path 仍可能写入。
- 工具调用审计与普通 Hermes run 不一致。
- 幂等、dryRun、runId、toolCallId 等字段无法统一治理。
-
-## 4. 建议修复
-
- 将 fast-path 的工具写入改为调用统一 tool executor。
- fast-path 只负责 prompt / plan，不直接执行写入函数。
- 增加 smoke：当对应 tool disabled 时，`page_ai_workflow` 不得绕过限制写入。
-
-## 5. 状态
-
-已确认 route 级绕过统一执行壳，尚未修复。
@@ -1,33 +0,0 @@
-# 7-21 [process][bug] mnote.doc.markdown_edit 本地文件写入绕过 dryRun / idempotency v1
-
-> 发现时间：2026-05-17
->
-> 状态：`[process]`
->
-> 关联主线：`07-ai`
-
-## 1. 问题定义
-
-`mnote.doc.markdown_edit` 的本地文件分支没有调用统一写入合同校验，也没有检查 `dryRun` 与 `idempotencyKey`，在匹配成功后直接 `fs::write`。
-
-## 2. 证据
-
- [doc.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/hermes_tools/doc.rs:714) 进入 `doc_markdown_edit` 后没有先调用 `ensure_write_contract`。
- [doc.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/hermes_tools/doc.rs:842) 注释说明本地文件直接写回。
- [doc.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/hermes_tools/doc.rs:845) 对本地路径执行 `fs::write`。
-
-## 3. 影响
-
- `dryRun=true` 时也可能落盘，违反工具预览语义。
- 缺少幂等键会让重试请求重复写入，尤其是 ACP / Hermes 断线重试场景。
- 本地 `.md` 与在线 Convex 文档的写入安全级别不一致。
-
-## 4. 建议修复
-
- 在 `doc_markdown_edit` 写入前统一调用 `ensure_write_contract`。
- 对 `dryRun=true` 返回 diff / preview，不落盘。
- 增加本地 `.md` dryRun 单测，断言文件内容不变。
-
-## 5. 状态
-
-已确认源码层缺陷，尚未修复。
@@ -1,35 +0,0 @@
-# 7-22 [process][bug] mnote.doc.apply_block_ops 批量写入缺少 revision / conflictDetectionKey 校验 v1
-
-> 发现时间：2026-05-17
->
-> 状态：`[process]`
->
-> 关联主线：`07-ai`
-
-## 1. 问题定义
-
-`mnote.doc.apply_block_ops` 的批量入口只校验 dryRun / idempotency 写入合同，没有调用页面 revision、conflictDetectionKey、blockRevisionRef 的写前校验。
-
-同文件中已有 `ensure_page_write_preconditions`，但该批量入口没有使用它。
-
-## 2. 证据
-
- [block.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/hermes_tools/block.rs:385) 定义 `doc_apply_block_ops`。
- [block.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/hermes_tools/block.rs:390) 仅调用 `ensure_write_contract`。
- [block.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/hermes_tools/block.rs:774) 存在 `ensure_page_write_preconditions`，但批量入口未调用。
-
-## 3. 影响
-
- AI 可能基于旧 `PageAggregate` 对正文写入，覆盖用户新编辑。
- 多轮 Hermes / ACP run 同时写入时缺少冲突保护。
- `markdown_edit` 在线分支会转调 `apply_block_ops`，因此该缺陷会影响 markdown 主路径。
-
-## 4. 建议修复
-
- `doc_apply_block_ops` 真实写入前必须校验 page revision 与 conflictDetectionKey。
- 块级操作应支持并校验 blockRevisionRef 或等价版本字段。
- 增加负向测试：缺少 revision / conflictDetectionKey 时真实写入必须拒绝。
-
-## 5. 状态
-
-已确认批量写入入口缺少必要冲突校验，尚未修复。
@@ -1,34 +0,0 @@
-# 7-23 [process][bug] mnote.doc.markdown_edit manifest schema 缺少 required 与写入字段 v1
-
-> 发现时间：2026-05-17
->
-> 状态：`[process]`
->
-> 关联主线：`07-ai`
-
-## 1. 问题定义
-
-`mnote.doc.markdown_edit` manifest 的 input schema 没有完整声明 `required` 字段，也缺少 `dryRun`、`idempotencyKey` 等写入合同字段。
-
-这会让模型、ACP wrapper 和外部调用方无法从 manifest 得知真实写入要求。
-
-## 2. 证据
-
- [manifest.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/hermes_tools/manifest.rs:413) 附近定义 `mnote.doc.markdown_edit` manifest。
- 当前 schema 更像参数提示，没有完整表达写入前置条件。
-
-## 3. 影响
-
- 调用方可能不传幂等字段或 dryRun 字段。
- tool toggle / schema validation 无法提前拒绝不合规请求。
- Reasonix / ACP 等多 runtime 接入时会继续复制不完整合同。
-
-## 4. 建议修复
-
- 为 `mnote.doc.markdown_edit` 补全 JSON Schema：`required`、互斥的 `operations` / `full_content`、写入合同字段。
- manifest 与 Rust runtime 校验保持一致。
- 增加 manifest snapshot 测试，防止字段再次漂移。
-
-## 5. 状态
-
-已确认 manifest 合同不完整，尚未修复。
@@ -1,35 +0,0 @@
-# 7-24 [process][bug] 在线 markdown_edit 写回不以最终 Markdown 为真源 v1
-
-> 发现时间：2026-05-17
->
-> 状态：`[process]`
->
-> 关联主线：`07-ai`
-
-## 1. 问题定义
-
-在线 Convex 文档的 `mnote.doc.markdown_edit` 先在 `md` 字符串上顺序应用 search/replace，但写回时没有用最终 `md` 生成新的文档真相，而是重新读取原始 blocks，并用原始 operations 反推 `apply_block_ops`。
-
-因此 markdown 层已经算出的最终结果不一定能被忠实落库。
-
-## 2. 证据
-
- [doc.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/hermes_tools/doc.rs:811) 在 `md` 上执行 search/replace。
- [doc.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/hermes_tools/doc.rs:855) 写回前重新读取 aggregate / blocks。
- [doc.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/hermes_tools/doc.rs:857) 使用原始 operations 构造 block ops，而不是解析最终 `md`。
-
-## 3. 影响
-
- 跨块替换、全文替换、标题 / 列表格式变化可能在 markdown 层成功，但无法正确转换成 block ops。
- 部分失败仍可能返回成功写入，用户看到的正文与工具返回摘要不一致。
- 该问题与 `7-17` 的同块多操作覆盖同源，但影响面更宽。
-
-## 4. 建议修复
-
- 在线分支应明确选择一种真源：要么最终 `md` 可被解析并完整生成 EditorBlockDocument，要么限制 `markdown_edit` 只支持可安全映射的单块操作。
- 对 full_content、跨块 search/replace、列表/标题变更增加回读一致性测试。
- route 成功条件必须从“operationsApplied > 0”提升为“Page Aggregate 回读等于预期最终 markdown”。
-
-## 5. 状态
-
-已确认写回层没有使用最终 markdown 真相，尚未修复。
@@ -1,92 +0,0 @@
-# 7-25 [process][bug] ACP Reasonix 页面 AI block_edit_workflow 在 markdown 命中后生成空 block_ops v1
-
-> 发现时间：2026-05-17
->
-> 状态：`[process]`
->
-> 关联主线：`07-ai`
->
-> 关联缺陷：`7-24 在线 markdown_edit 写回不以最终 Markdown 为真源`
-
-## 1. 用户可见症状
-
-在页面 AI 中切换到 `ACP · Reasonix`，输入：
-
-```text
-你
-检查你是否能读取到本页第一段，同时请修改第二段为：测试123
-```
-
-工具调用失败：
-
-```text
-mnote.page_ai.block_edit_workflow 失败 · page-ai-fast-mp9wm0qo
-结果 mnote.doc.apply_block_ops operations 不能为空
-```
-
-## 2. 问题定义
-
-`page_ai.block_edit_workflow` 当前已切到：
-
-```text
-模型输出 search/replace
-> mnote.doc.markdown_edit
-> 在线文档再转换为 mnote.doc.apply_block_ops
-```
-
-但在线写回层没有以最终 Markdown 为真源。它在 markdown 字符串中 search/replace 成功后，又用原始 `operations` 去原始 `blocks` 中反查目标块。如果反查不到块，就生成空 `block_ops`，随后仍调用 `mnote.doc.apply_block_ops`，最终抛出“operations 不能为空”。
-
-## 3. 证据
-
- [page_ai_workflow.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/routes/page_ai_workflow.rs:69) 调用模型生成 markdown operations。
- [page_ai_workflow.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/routes/page_ai_workflow.rs:91) 构造 `mnote.doc.markdown_edit` 输入。
- [doc.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/hermes_tools/doc.rs:811) 在 `md` 字符串上执行 search/replace。
- [doc.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/hermes_tools/doc.rs:857) 调用 `build_block_ops_from_markdown_edit`。
- [doc.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/hermes_tools/doc.rs:989) 只用 `block.text.contains(search)` 反查 block。
- [doc.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/hermes_tools/doc.rs:1008) 可能返回空 `block_ops`。
- [doc.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/hermes_tools/doc.rs:878) 即使 `block_ops` 为空，也继续调用 `doc_apply_block_ops`。
- [block.rs](/mnt/Data1T/mnote/rust/crates/mnote-web/src/hermes_tools/block.rs:405) 对空 operations 报错：`mnote.doc.apply_block_ops operations 不能为空`。
-
-## 4. 根因判断
-
-这条错误不是最终 root cause，只是下游暴露出来的症状。
-
-真正根因是 markdown 层与 block ops 写回层存在二次定位：
-
-1. `search_replace(&md, search, replace)` 可以通过精确、归一化或 fuzzy 匹配成功。
-2. `build_block_ops_from_markdown_edit` 却只支持 `block.text.contains(search)`。
-3. 两套匹配规则不一致时，markdown 层显示已命中，block 层却生成空 operations。
-4. 空 operations 没有在 `markdown_edit` 层转成语义化错误，而是继续传给 `apply_block_ops`。
-
-## 5. 影响
-
- ACP Reasonix 的页面编辑会向用户暴露底层 `apply_block_ops` 错误，而不是说明“markdown 命中但无法映射到块”。
- “读取第一段 + 修改第二段”这类混合任务可能进入 fast workflow，但该 workflow 只能表达写入，不保证先读后答。
- 如果模型给出的 `search` 是段落序号、fuzzy 片段、带格式文本或跨块文本，markdown 层可能成功，block 写回层仍失败。
-
-## 6. 建议修复
-
-短期：
-
- `doc_markdown_edit` 在调用 `doc_apply_block_ops` 前，如果 `applied > 0` 但 `block_ops.is_empty()`，应返回明确错误，例如 `mnote_doc_markdown_edit_block_mapping_empty`，并包含 failed operation 的 search 摘要。
- `page_ai_workflow` 应把该错误翻译为用户可理解的提示，不要暴露 `apply_block_ops operations 不能为空`。
-
-中期：
-
- `build_block_ops_from_markdown_edit` 必须复用 `search_replace` 的定位结果，或让 `search_replace` 返回原始命中范围 / paragraph / block 映射。
- 对“第一段/第二段”等序号型指令，应由模型输出对应段落原文作为 `search`，并增加回读校验。
-
-长期：
-
- 按 `7-24` 收口：在线 `markdown_edit` 应以最终 Markdown 为写回真源，或明确限制只支持可安全映射的单块精确替换。
-
-## 7. 复现 / 验证建议
-
- 浏览器 smoke：ACP Reasonix，页面含至少两段正文，输入“检查第一段并修改第二段为：测试123”。
- 断言失败时错误码不能是 `mnote.doc.apply_block_ops operations 不能为空`，应是 markdown 到 block 映射失败的明确错误。
- 修复后回读 Page Aggregate，断言第二段实际变为 `测试123`，同时 AI 回复能正常说明已读取到第一段。
-
-## 8. 状态
-
-已按用户反馈与源码路径确认缺陷，尚未修复。
-
@@ -1,102 +0,0 @@
-# 页面 AI 块编辑 — model 主路径操作缺少 content（direct path 架构定位错误）
-
-> 发现时间：2026-05-16
->
-> 更新时间：2026-05-16（架构定位修正）
->
-> 状态：`[process]`
->
-> 关联主线：`07-ai` / `05-editor-mainline`
->
-> 关联设计稿：`design/07-ai/done/7-13-page-block-editor-runtime-actor-v1.md`
->
-> 关联代码：
-> - `rust/crates/mnote-web/src/routes/page_ai_workflow.rs` — block_edit_workflow, direct_block_edit_operations（应退役）, call_block_edit_model（唯一正确路径）
-> - `rust/crates/mnote-web/src/hermes_tools/block.rs:436` — doc_apply_block_ops, replace 操作缺少 content
-
-## 症状
-
-用户用自然语言在页面 AI 面板输入块编辑指令时，`mnote.page_ai.block_edit_workflow` 返回 400：
-
-```
-replace 操作缺少 content
-```
-
-## 复现步骤
-
-1. 打开任意文档
-2. 点击右下角「AI 助手」
-3. 输入自然语言指令，如 `把第一段文字改成：AI成功修改了这一段。`
-4. → `POST /api/page-ai/block-edit-workflow` 返回 400
-5. 页面上显示 `mnote.page_ai.block_edit_workflow 失败`
-
-## 架构问题：两条路径的设计是错误的
-
-当前 `block_edit_workflow` 有两条路径，但**正确的路径只有一条**：
-
-### 唯一正确路径：Model path（`call_block_edit_model`）
-
-```
-用户自然语言 → 模型理解语义 → 产出 operations JSON → doc_apply_block_ops → 写入
-```
-
-这是 AI 面板应有的行为：用户说人话，模型理解意图，产出操作。这是**唯一主路径**。
-
-### 应退役路径：Direct path（`direct_block_edit_operations`）
-
-```
-用户特定格式 → 正则抠「」内文本 → 直接拼 operations → 写入
-```
-
-这不是 AI，这是**命令行**。它要求用户按固定格式输入（「」引号），本质是把 AI 面板当成 shell 在用。当前它"能用"只是因为绕过了模型调用，看起来"快"，但：
- 不能处理自然语言（"把这段话改简洁一些"）
- 不能批量推理（"把所有 TODO 改成已完成"）
- 不能跨块理解（"把第一段和第二段合并"）
- 和 AI 对话的本意完全背离
-
-**结论**：direct path 应该退役，model path 是唯一主路径。
-
-## 当前 model 主路径的具体缺陷
-
-系统 prompt（`page_ai_workflow.rs:274`）只说了 `op` 四选一，**没有告诉模型每种 operation 需要的字段**：
-
-```
-当前 prompt:
-"operations 的 op 只能是 replace、insert_after、delete、move_after。优先使用 page_xml 中的 block id；禁止输出解释文字。"
-
-缺少的信息:
- replace 需要 blockId（或 matchText）+ content
- insert_after 需要 blockId（或 matchText）+ content
- delete 只需要 blockId（或 matchText）
- move_after 需要 blockId + targetBlockId
-```
-
-模型不知道 schema，自然会漏掉 `content` 字段。DeepSeek v4 Flash 的 `response_format: json_object` 只保证输出是合法 JSON，不保证字段齐全。
-
-## 更深层问题：块操作粒度是否合理
-
-当前 AI 编辑通过 `operations: [{ op: "replace", blockId: "...", content: "..." }]` 这种逐个块操作的方式执行。但：
-
-1. **mnote 的在线文档本质上是一个 markdown 文件**，Tiptap 只是其块级 UI 表现层
-2. **本地 md 文件模式**下，Tiptap 退化为纯显示层，编辑直接在 markdown 文本上进行
-3. 在线文档应该**向本地文档靠拢**——对 AI 而言，最自然的编辑方式是"给我一段 markdown，我返回修改后的 markdown"，而不是"给我 blocks 数组，我逐个块产出 op"
-
-如果在线文档和本地文档走两套 AI 编辑口径（一套块操作、一套文本操作），长期维护成本翻倍。
-
-## 建议修复方向
-
-### 立即修复（让 model 主路径可用）
-1. **补全 system prompt 的 operation JSON schema**：明确 replace/insert_after 需要 `content` 字段，给出完整示例
-
-### 架构收口（应该做的）
-2. **退役 direct path**：`direct_block_edit_operations` + `quoted_segments` 整条路径标记 deprecated
-3. **考虑降低块操作粒度**：AI 编辑是否可以走 markdown diff 而非逐个块 ops？在线文档和本地 md 能否共用同一条 AI 写入路径？
-4. **在线/本地口径收敛**：在 `design/07-ai/` 中明确在线文档 AI 编辑应向本地 md 的简洁模型靠拢
-
-## 证据
-
- Browser smoke (2026-05-16)：
-  - Direct path（「」quote，本质是命令行）: ✅ 177ms — 这说明不了 AI 能力，只是正则匹配
-  - Model path（自然语言，真 AI）: ❌ 400，replace 缺少 content
- 代码：`page_ai_workflow.rs` system prompt 缺 operation schema
- 用户反馈：direct path 不是 AI 面板应有的行为，应退役